IMS

IP Multimedia Subsystem
CAPITULO 02
PLANO DE SEALIZACION
Universidad Nacional de Ingeniera
ARQUITECTURA DE IMS
Debemos recordar que la 3GPP
estandariza funciones. Por lo tanto
la arquitectura se define como un
conjunto de funciones y las
interfaces capaces de enlazarlas.
Esto permite escoger a los
implementadores combinar varias
funciones en un solo nodo.
SIP SESSION INITIATION PROTOCOL
SIP
Session Initiation Protocol es un protocolo que se encarga del manejo de sesiones
en internet: establecimiento, mantenimiento y desconexion. Esta orientado a
manejar sesiones multimedia.
Su especificacin la encontramos en el RFC 3261. Aunque hay nuevos
documentos que extienden sus funcionalidades.
Una caracterstica importante de SIP es que utiliza mensajes de texto para el
manejo de las sesiones, igual como lo hacen HTTP y SMTP.
SDP
Uno de los objetivos principales de SIP es entregar la descripcin de la sesin a un
usuario SIP en la ubicacin que se encuentre. Una vez que el usuario ha sido
ubicado y la descripcin inicial de la sesin ha sido establecida SIP puede realizar
modificaciones sobre la sesin as como terminarlas en le momento que sea
necesario.
La descripcin de sesin debe contener suficiente informacin para que un
usuario SIP pueda participar de la sesin: nombre, direccin IP, puerto,
caractersticas de la media que se va transportar. El formato que utiliza SIP es SDP
(Session Description Protocol) RFC2327, aunque su nombre indique que es un
protocolo en realidad es un formato de texto que permite describir la sesin.
SDP Modelo Oferta/Respuesta
El intercambio de las descripciones de sesin se hacen siguiendo el modelo
Oferta/Respuesta. Para establecer una sesin no es suficiente que solo el
dispositivo llamante enve un descripcin de sesin, sino que el llamante tambin
describa sus condiciones para determinar si es posible establecer una
comunicacin.
Para esto el modelo oferta/respuesta garantiza un descripcin de sesin en dos
sentidos: El terminal que inicia la sesin enva una oferta (descripcin de sesin)
al terminal destino, este responde con una nueva descripcin de sesin.
SDP
v=0
o=rgonzales 2790844676 2867892807 IN IP4 192.0.0.1
s=Sesion de prueba
c=IN IP4 192.0.0.1
t=0 0
m=audio 20000 RTP/AVP 0
a=sendrecv
m=video 20002 RTP/AVP 31
a=sendrecv
v=0
o=arodriguez 234562566 236376607 IN IP4 192.0.0.2
s=Sesion de Prueba
c=IN IP4 192.0.0.2
t=0 0
m=audio 30000 RTP/AVP 0
a=sendrecv
m=video 30002 RTP/AVP 31
a=sendrecv
Oferta
Respuesta
Nota: Codecs
0 G.711 uLaw
31 H261
SDP
Tipos SDP
v - Protocol version
b - Bandwidth information
o - Owner of the session and session identifier
z - Time zone adjustments
s - Name of the session
k - Encryption key
i -Information about the session
a - Attribute lines
u - URL containing a description of the session
t - Time when the session is active
e - Email address to obtain information about the session
t - Times when the session will be repeated
p - Phone number to obtain information about the session
m - Media line
c - Connection information
i - Information about the media line
SIP URI (UniformResource Identifier)
El intercambio de las descripciones de sesin se hacen siguiendo el modelo
Oferta/Respuesta. Para establecer una sesin no es suficiente que solo el
dispositivo llamante enve un descripcin de sesin, sino que el llamante tambin
describa sus condiciones para determinar si es posible establecer una
comunicacin.
Algunos ejemplos de URIs:
sip:Renatto.Gonzales@domain.com
sip:Renatto.Gonzales@domain.com;transport=tcp
ENTIDADES SIP
SIP Agentes de Usuario (UA)
Un agente de usuario es un dispositivo terminal con funcionalidad SIP. El UA
recibe comandos de un usuario (una persona u otro protocolo) y acta iniciando o
terminando sesiones con otros UA. El UA debe mantiene el estado de las
llamadas que inicia o recibe.
El UA contiene tanto una aplicacin cliente y una servidor:
- UAC (User Agent Client) Se encarga de iniciar solicitudes.
- UAS (User Agent Server) Se encarga de generar respuestas.
Durante una sesin el UA acta como ambos cliente y servidor a la vez.
El UA tambin debe soportar SDP para la descripcin de medios.
SIP - Agentes de Usuario (UA)
INVITE
180 Ringing
200 OK
ACK
MEDIA (no SIP)
BYE
200 OK
Establecimiento de sesin directo entre dos
terminales SIP, normalmente esto ocurre cuando
se conoce la ubicacin del terminal llamado.
La comunicacin empieza con el envo de un
paquete INVITE al terminal llamado.
El paquete INVITE lleva los detalles de la sesin
que se esta intentando establecer.
La informacin (MEDIA) viaja utilizando otro
protocolo normalmente RTP.
UAC UAS
SIP B2BUA
El Back-to-Back User Agent es un tipo de dispositivo SIP, que recibe solicitudes SIP,
las reformula y las reenva como si fueran solicitudes nuevas. Se suelen utilizar
para la implementacin de nuevos servicios.
El B2BUA opera entre los dos terminales igual que el proxy SIP, pero divide el
intercambio de mensajes en dos flujos de llamadas diferentes.
SIP - B2BUA
B2BUA
100 Trying
MEDIA (no SIP)
INVITE
180 Ringing
100 Trying
INVITE
180 Ringing
200 OK
ACK
200 OK
ACK
200 OK
ACK
MEDIA (no SIP)
200 OK
ACK
Como tanto los mensajes de
control SIP e incluso la Media
pasa a travs del B2BUA, es
posible implementar
caractersticas de valor
agregado durante la llamada.
SIP B2BUA
En el flujo original el B2BUA acta como UAS y procesa la solicitud como un UAC hacia el
terminal destino., manejando la sealizacin entre ambos extremos. El B2BUA mantiene el
estado completo de las llamadas que maneja.
Es por eso que el B2BUA puede realizar tareas como:
- Gestin de las llamadas.
- Facturacin de llamadas.
- Monitoreo de llamadas.
- Desconexin de llamadas.
- Transferencia de llamadas.
SIP Gateway
El Gateway SIP es la aplicacin que hace interface entre una red SIP y una red que
utiliza otro protocolo de sealizacin. Se puede considerar como un tipo especial
de UA que trabaja para un protocolo.
Los gateways SIP terminan la ruta de sealizacin y en algunos casos tambin la
ruta de la informacin.
GWSIP H323, termina la ruta de sealizacin SIP y la convierte en sealizacin
para H323. Sin embargo la informacin es intercambiada entre el SIP UA y el
terminal H323 utilizando RTP.
GW SIP PSTN, termina la ruta de sealizacin SIP y la convierte en sealizacin
para la PSTN. En este caso tambin termina la ruta de la informacin del flujo RTP
dentro de una red IP y lo convierte en una troncal tradicional dela PSTN.
SIP - Servidores
Los Servidores SIP son aplicaciones que aceptan solitudes SIP y las
responden. El protocolo SIP define varios tipos de servidor, todas estas
definiciones son de funciones lgicas, por lo tanto estas pueden ser
agrupadas en un solo nodo.
- SIP Proxy Server.
- SIP Redirect Server.
- SIP Registrar Server.
- SIP Location Server.
SIP - PROXY
Un proxy SIP recibe solicitudes SIP UA o de otros Proxis y reenva las solicitudes hacia el
destino. Normalmente tiene acceso a una base de datos de ubicacin (Location Server)
para determinar el siguiente salto cuando atiende solicitudes entrantes.
La diferencia de un Proxy con un UA o un Gateway es la siguiente:
- El proxy no genera solicitudes. Solo responde a solicitudes o las reenva.
- El proxy no tiene capacidades para manejo de media.
- El proxy no lee el cuerpo de los mensajes SIP solo las cabeceras.
EL proxy SIP no es un B2BUA ya que no modifica el contenido de la sealizacin ni de la
informacin dentro de una conversacin.
SIP - Proxy Server
Proxy Server
180 Ringing
200 OK
ACK
MEDIA (no SIP)
BYE
200 OK
INVITE
180 Ringing
200 OK
ACK
INVITE
Normalmente el terminal llamante
no conoce la ubicacin del
terminal llamado. Por eso es
necesario el uso de un proxy.
El Proxy SIP recibe el mensaje de
Invitacin, utiliza la URI del
llamado y lo busca hasta encontrar
su direccin IP. Luego reenva los
mensajes hasta que se establezca
la comunicacin.
El proxy SIP no maneja el
establecimiento de sesin, ni tiene
control sobre la informacin que
se enva.
SIP - PROXY
Los UA son configurados con un
Outbound Proxy dentro de su
dominio al cual le enviaran las
solicitudes. Aqu se autentican los
UAs.
El Inbound proxy recibe las
solicitudes de otro proxy y
consulta al servicio de ubicacin
de su zona para enrutar la
solicitud a UA llamado.
Cada Proxy atiende en su respectivo dominio.
SIP FORKING PROXY
Este proxy mantiene un registro de las
solicitudes enviadas y las respuestas de
cada una. Es til cuando es necesario
enviar una solicitud a diferentes
posibles ubicaciones del destino.
SIP REDIRECT SERVER
Un servidor de redireccin recibe
solicitudes las responde, pero no las
reenva. Igual que el servidor Proxy
utiliza un servicio de ubicacin para
buscar la informacin de los UAs.
Sin embargo en vez de reenviar la
informacin hacia el UA encontrado, lo
que hace es devolver la ubicacin del
UA destino al UA que hizo la solicitud.
Su trabajo concluye despus de recibido
el ACK.
Redirect Server
302 Moved Temporarily
ACK
MEDIA (no SIP)
BYE
200 OK
INVITE
180 Ringing
200 OK
ACK
INVITE
SIP REGISTRAR SERVER
Un servidor de registro acepta solicitudes SIP REGISTER. El servidor de
registro crea una relacin temporal entre el AOR URI y el URI del dispositivo
desde el cual se esta registrando el UA.
De esta manera se mantiene disponible la informacin de los UAs
registrados dentro del mismo dominio administrativo para los Proxies y
servidores de redireccin.
Los servidores de registro pueden solicitar la autenticacin de los Uas que
se intentan registrar.
Como respuesta a cualquier otra solicitud responde: 501 Not Implemented.
SIP REGISTRAR SERVER
REGISTER
200 OK
Registrar Server
registrar.sipdomain.com
UA
REGISTER sip:registrar.sipdomain.com SIP/2.0
To: Renatto Gonzales <sip:rgonzales@sipdomain.com>
From: Renatto Gonzales <sip:rgonzales@sipdomain.com>
Call-ID: 23@200.201.202.203
Cseq: 1 REGISTER
Contact: Sip:rgonzales@uni.edu.pe
Content-Length: 0
MENSAJES SIP
SIP - FORMATO DE MENSAJES
SIP es un protocolo de pregunta/respuesta basado en texto, su diseo se basa en
el protocolo HTTP. Cada transaccin SIP esta conformada por una solicitud del
cliente, una o mas respuestas provisionales (opcionales) y una respuesta final del
servidor.
Lnea de inicio.
Campos de la cabecera.
Lnea vaca.
Cuerpo del mensaje. Opcional.
Tambin se le llama REQUEST LINE durante las
solicitudes y STATUS LINE durante las respuestas.
Los campos de la cabecera estn en el formato
campo:valor.
REQUEST LINE
Se conforma del nombre del mtodo que indica el propsito de la solicitud, la URI
solicitada que apunta al destino de la comunicacin y la versin del protocolo SIP.
INVITE sip:renatto.gonzales@domain.com SIP/2.0
Nombre del Mtodo. Versin del protocolo.
La URI solicitada.
REQUEST LINE
STATUS LINE
Se conforma de la versin del protocolo y el estado de la transaccin. Este ultimo
se entrega como status code (formato numrico) y status phrase (formato texto)
que puede ser escrito en cualquier idioma.
SIP/2.0 108 Ringing
Versin del protocolo.
Status phrase.
Status code.
STATUS LINE
CAMPOS DE LA CABECERA
Los campos de la cabecera estn justo despus de la lnea de inicio, hay campos
obligatorios y campos que son opcionales. Estn conformados por el nombre del
campo y un valor separados por dos puntos.
sip: renatto.gonzales@uni.edu.pe
Nombre del campo
Valor
Cuando un campo tiene mas de una entrada dentro del mismo mensaje puede
expresarse de cualquiera de estas dos formas:
Route: <sip:p30.uni.edu.pe>, <sip:p34.inictel-uni.pe> Route: <sip:p30.uni.edu.pe>
Route: <sip:p34.inictel-uni.pe>
CAMPOS DE LA CABECERA
Algunos de los campos mas resaltantes son:
To. Contiene el URI del destino de la solicitud. Sin embargo esta URI no se utiliza para rutear la
solicitud. Su propsito es para el filtrado de mensajes.
From. Contiene la URI del originador del mensaje. Su propsito es para el filtrado de mensajes.
Cseq. Contiene un numero de secuencia y el nombre de un mtodo. Se utiliza para identificar
las solicitudes y respuestas.
Call-ID. Provee el identificador nico para un intercambio de mensajes SIP.
Max-Forwards. Evita los lazos de ruteo. Cada proxy que pasa una solicitud decrementa el
valor en 1, si llega a 0 la solicitud se descarta.
Via. Mantiene la pista de los proxies que han sido atravesados. El mensaje de respuesta utiliza
estos campos para recorrer los mismos proxies en el camino de regreso.
CUERPO DEL MENSAJE
El cuerpo del mensaje lleva informacin codificada con MIME (Multipurpose
Internet Mail Extension), el RFC 2045 define este formato para enviar mltiples
adjuntos con diferentes formatos dentro de un correo electrnico. Normalmente
los campos en la cabecera proveen informacin sobre su longitud, su formato y
como debe ser manejado. El cuerpo del mensaje se transmite extremo a extremo
por lo que los porxies solo leen la cabecera pero no el cuerpo.
Descripcin de sesin
Content-Disposition: session
Content-Type: application/sdp
Content-Length: 193
CUERPO DEL MENSAJE
Content-Type: multipart/mixed; boundary="0806040504000805090"
Content-Length: 384
--0806040504000805090
Content-Type: application/sdp
Content-Disposition: session
v=0
o=Renatto 2790844676 2867892807 IN IP4 192.0.0.1
s=Clase de IMS
c=IN IP4 192.0.0.1
t=0 0
m=audio 20000 RTP/AVP 0 8
a=sendrecv
m=video 20002 RTP/AVP 31
a=sendrecv
--0806040504000805090
Content-Type: text/plain
This is the second body part
--0806040504000805090--
Nota: Codecs
0 G.711 uLaw
8 G.711 aLaw
31 H261
SDP
Tipos SDP
v - Protocol version
b - Bandwidth information
o - Owner of the session and session identifier
z - Time zone adjustments
s - Name of the session
k - Encryption key
i -Information about the session
a - Attribute lines
u - URL containing a description of the session
t - Time when the session is active
e - Email address to obtain information about the session
t - Times when the session will be repeated
p - Phone number to obtain information about the session
m - Media line
c - Connection information
i - Information about the media line
TRANSACCION SIP
SIP define 3 tipos de transacciones:
REGULAR:
Es cualquier transaccin
menos una que involucre
INVITE, ACK o CANCEL.
TRANSACCION SIP
INVITE-ACK
Involucra dos transacciones:
INVITE El UAS recibe la
solicitud de INVITE y puede
generar ninguna o mas
respuestas provisionales y una
respuesta final.
ACK cuando el UAC recibe la
respuesta final, genera una
solicitud de ACK pero no
recibe ninguna respuesta
asociada.
TRANSACCION SIP
CANCEL
Las transacciones de
cancelacin se parecen a las
regulares pero siempre estn
relacionadas a una transaccin
anterior. La respuesta final la
genera el siguiente salto,
normalmente un proxy en vez
del UAS.
FLUJO DE MENSAJES ESTABLECIMIENTO DE SESION
REGISTER sip:registrar.uni.edu.pe SIP/2.0
Via: SIP/2.0/UDP 192.0.0.1:5060; branch=z9hG4bKna43f
Max-Forwards: 70
To: Renatto Gonzales <sip:rgonzales@uni.edu.pe>;tag=453448
From: Renatto Gonzales <sip:rgonzales@smartphone.com>
Call-ID: 843528637684230998sdasdsfgt
Cseq: 1 REGISTER
Contact: <sip:rgonzales@smartphone.com>
Content-Length: 0
REGISTER
200 OK
PROXY SERVER
(Registrar Server)
registrar.uni.edu.pe
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.0.1:5060;branch=z9hG4bKna43f;received=192.0.0.1
To: Renatto Gonzales <sip:rgonzales@uni.edu.pe>;tag=54262
From: Renatto Gonzales <sip:rgonzales@smartphone.com>
Call-ID: 843528637684230998sdasdsfgt
Cseq: 1 REGISTER
Contact: <sip:rgonzales@smartphone.com>
Content-Length: 0
rgonzales
@Smartphone.com
FLUJO DE MENSAJES ESTABLECIMIENTO DE SESION
PROXY SERVER
proxi.uni.edu.pe
192.0.0.100
200 OK
ACK
MEDIA (no SIP)
BYE
200 OK
INVITE
200 OK
INVITE
arodriguez
192.0.0.2
rgonzales
192.0.0.1
sip:rgonzales@uni.edu.pe
sip:rgonzales@smarthphone.com
contact:
rgonzales@192.0.0.1
contact:
rgonzales@192.0.0.1
sip:rgonzales@192.0.0.1
sip:rgonzales@192.0.0.1
1
2
4
5
6
8
7
FLUJO DE MENSAJES ESTABLECIMIENTO DE SESION
INVITE sip:rgonzales@uni.edu.pe SIP/2.0
Via: SIP/2.0/UDP 192.0.0.2:5060;branch=z9hG4bK74gh5
Max-Forwards: 70
From: Alfredo Rodriguez <sip:arodriguez@uni.edu.pe>;tag=9hx34576sl
To: Renatto Gonzales <sip:rgonzales@uni.edu.pe>
Call-ID: 6328776298220188511@192.0.0.2
Cseq: 1 INVITE
Contact: <sip:arodriguez@192.0.0.2>
Content-Type: application/sdp
Content-Length: 138
v=0
o=arodriguez 2890844526 2890844526 IN IP4 192.0.0.2
s=-
c=IN IP4 192.0.0.2
t=0 0
m=audio 20000 RTP/AVP 0
1
FLUJO DE MENSAJES ESTABLECIMIENTO DE SESION
INVITE sip:rgonzales@Smartphone.com SIP/2.0
Via: SIP/2.0/UDP proxy.uni.edu.pe:5060;branch=z9hG4bK543fg
Via: SIP/2.0/UDP 192.0.0.2:5060;branch=z9hG4bK74gh5;received=192.0.0.2
Max-Forwards: 69
From: Alfredo Rodriguez <sip:arodriguez@uni.edu.pe>;tag=9hx34576sl
To: Renatto Gonzales <sip:rgonzales@uni.edu.pe>
Call-ID: 6328776298220188511@192.0.0.2
Cseq: 1 INVITE
Contact: <sip:arodriguez@192.0.0.2>
Content-Type: application/sdp
Content-Length: 138
v=0
o=arodriguez 2890844526 2890844526 IN IP4 192.0.0.2
s=-
c=IN IP4 192.0.0.2
t=0 0
m=audio 20000 RTP/AVP 0
2
FLUJO DE MENSAJES ESTABLECIMIENTO DE SESION
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.uni.edu.pe:5060;branch=z9hG4bK543fg;received=192.0.0.100
Via: SIP/2.0/UDP 192.0.0.2:5060;branch=z9hG4bK74gh5;received=192.0.0.2
From: Alfredo Rodriguez <sip:arodriguez@uni.edu.pe>;tag=9hx34576sl
To: Renatto Gonzles <sip:rgonzales@uni.edu.pe>;tag=1df345fkj
Call-ID: 6328776298220188511@192.0.0.2
Cseq: 1 INVITE
Contact: <sip:rgonzales@192.0.0.1>
Content-Type: application/sdp
Content-Length: 132
v=0
o=rgonzales 2890844545 2890844545 IN IP4 192.0.0.1
s=-
c=IN IP4 192.0.0.1
t=0 0
m=audio 30000 RTP/AVP 0
3
FLUJO DE MENSAJES ESTABLECIMIENTO DE SESION
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.0.2:5060;branch=z9hG4bK74gh5;received=192.0.0.2
From: Alfredo Rodriguez <sip:arodriguez@uni.edu.pe>;tag=9hx34576sl
To: Renatto Gonzles <sip:rgonzales@uni.edu.pe>;tag=1df345fkj
Call-ID: 6328776298220188511@192.0.0.2
Cseq: 1 INVITE
Contact: <sip:rgonzales@192.0.0.1>
Content-Type: application/sdp
Content-Length: 132
v=0
o=rgonzales 2890844545 2890844545 IN IP4 192.0.0.1
s=-
c=IN IP4 192.0.0.1
t=0 0
m=audio 30000 RTP/AVP 0
4
FLUJO DE MENSAJES ESTABLECIMIENTO DE SESION
ACK sip:rgonzales@192.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.0.2:5060;branch=z9hG4bK74765
Max-Forwards: 70
From: Alfredo Rodriguez <sip:arodriguez@uni.edu.pe>;tag=9hx34576sl
To: Renatto Gonzales <sip:rgonzales@uni.edu.pe>;tag=1df345fkj
Call-ID: 6328776298220188511@192.0.0.2
Cseq: 1 ACK
Contact: <sip:arodriguez@192.0.0.2>
Content-Length: 0
5
FLUJO DE MENSAJES ESTABLECIMIENTO DE SESION
BYE sip:rgonzales@192.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.0.2:5060;branch=z9hG4bK745gh
Max-Forwards: 70
From: Alfredo Rodriguez <sip:arodriguez@uni.edu.pe>;tag=9hx34576sl
To: Renatto Gonzales <sip:rgonzales@uni.edu.pe>;tag=1df345fkj
Call-ID: 6328776298220188511@192.0.0.2
Cseq: 2 BYE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.0.2:5060;branch=z9hG4bK745gh;received=192.0.0.2
From: Alfredo Rodriguez <sip:arodriguez@uni.edu.pe>;tag=9hx34576sl
To: Renatto Gonzales <sip:rgonzales@uni.edu.pe>;tag=1df345fkj
Call-ID: 6328776298220188511@192.0.0.2
Cseq: 2 BYE
Content-Length: 0
7
6
CONCLUSIONES