Modulo 1 Sip Ucb - 2017

SIP
Prof. Mgtr. Ing. Ral Gardella
rgardella@speedy.com.ar
SIP (Session Initiation Protocol)
RFC 3261 (anteriormente RFC 2543)
Es un protocolo de sealizacin basado en texto
usado para crear y controlar sesiones
multimedia con dos o ms participantes
Es un protocolo cliente-servidor transportado
sobre TCP o UDP, pero las implementaciones
ms comunes usan SIP sobre UDP por
simplicidad y velocidad
SIP es un protocolo mucho ms simple que
H.323 pero tan funcional como l. SIP tiene
mayor performance, flexibilidad y escalabilidad
SIP (Session Initiation Protocol)
Tiene sus races en protocolos de texto
anteriores tales como HTTP
Diagramas de topologa de redes usando
sealizacin SIP son muy similares a los de
H.323
La red de la siguiente figura muestra dos
dominios conectados va una nube de ruteo,
cada uno implementando sealizacin SIP
Dos dominios usando
sealizacin de llamadas SIP
Elementos de un sistema SIP
Un sistema SIP consiste de agentes de usuario (UA) y
uno o ms servidores
Agente de usuario (UA)
Es una aplicacin que inicia, recibe y termina llamadas.
User Agent Client (UAC): entidad que inicia una llamada
User Agent Server (UAS): entidad que recibe una llamada
Tanto UAC como UAS puede terminar una llamada
Sistemas SIP pueden estar en:
Segmentos de red dedicados
Segmentos de red conectados a travs de la Internet pblica
Redes de empresas que tambin soportan otros protocolos de
sealizacin IP
Servidores SIP pueden operar como servicios de proxy
o redirect
Servidores proxy ejecutan sealizacin de llamadas en
nombre de las partes a quienes sirven
Actan tanto como un servidor y como un cliente para hacer
requerimientos en nombre de otros clientes
Interpretan, reescriben o traducen un mensaje de requerimiento
antes de reenviarlo
Servidores redirect determinan la ubicacin actual de
la parte llamada e instruyen a la parte llamante a iniciar
sealizacin con la parte llamada directamente
Acepta un requerimiento SIP y mapea la direccin en otras que
retorna al cliente
A diferencia de un proxy server no inicia su propio
requerimiento SIP
A diferencia de un UAS no acepta o termina llamadas
Ambos conceptos de sealizacin de llamadas son
similares a los modelos de ruteo a travs de gatekeeper
y de ruteo directo de H.323, respectivamente
Location service: se usa por un SIP redirect o

proxy server para obtener informacin sobre posibles
localizaciones de la parte llamada
Registrar server: un servidor que acepta requerimientos

REGISTER.
Puede soportar autenticacin
Est tipicamente co-localizado con un proxy o redirect server y
puede ofrecer location services
USER
AGENT
DNS Location
Server Service
RED A
PROXY
SERVER
Proxy Proxy
Server Server REDIRECT
SERVER
RED B RED C
UAC UAS
Aspectos claves de SIP
1) Establecimiento de llamada: SIP es
autocontenido para establecer conferencias
punto a punto y multipunto
2) Servicios de localizacin de usuarios: usuarios

tienen la habilidad de moverse a otras
ubicaciones y acceder a sus servicios de
telefona desde localizaciones remotas. Este es
el servicio equivalente al provisto por RAS en
H.323
3) Capacidades de usuario: determinacin de la
media y parmetros de media a ser usados. SIP
usa el formato del protocolo SDP para negociar
parmetros de media as como H.323 usar la
sealizacin H.245
4) Disponibilidad del usuario: determinacin del
deseo de la parte llamada para entrar en
comunicacin. SIP define cdigos de respuesta
muy explcitos con informacin sobre la
disponibilidad actual de un usuario
5) Manejo de llamadas: incluye transferencia de
una llamada establecida, etc. Esto es importante
para servicios de telefona en una red pblica
SIP usa URIs (uniform resource identifiers)

para identificar direcciones de fuente, destino y
redireccionamiento
Se puede incluir en el URI el nmero de port
El nmero de port UDP bien conocido para SIP
es 5060
Ejemplo de formato de direcciones URI
Como los otros protocolos de sealizacin, SIP

tambin especifica el uso de RTP para transporte de
media y de RTCP para control de media
Mtodos SIP
SIP usa seis mtodos para sealizacin que son
explicados a continuacin
INVITE: inicia una llamada invitando a un usuario a
participar en una sesin
ACK: confirma que el cliente ha recibido una respuesta
final a un requerimiento INVITE
BYE: indica terminacin de la llamada
CANCEL: cancela un requerimiento pendiente
REGISTER: registra el agente de usuario
OPTIONS: usado para consultar las capacidades de un
server
Metodologa de sealizacin
SIP
INVITE
Este es el primer mensaje enviado por la parte llamante
Contiene informacin en el header SIP que identifica a la parte
llamante, call-ID, called party, call sequence number, entre
otras cosas (ver definicin de header SIP)
Basicamente, indica que una llamada est siendo iniciada.
Puede ser enviado durante una llamada para modificar el estado
de operacin de una llamada (por ej. colocar una parte on
hold)
El mensaje INVITE usualmente contiene una descripcin SDP de
parmetro llamada, tal como tipo de media y direcciones de
transporte. Cuando se ofrece una eleccin mltiple de
parmetros SDP, los elegidos se envan con el cdigo success
(200) en el mensaje de respuesta
SIP
ACK
El agente llamante responde con ACK slo a
requerimientos INVITE que han sido
satisfactoriamente aceptados con un cdigo 200
El cuerpo del mensaje ACK puede contener la
descripcin SDP de la capacidad de tipo de media de
la parte llamada
Si la respuesta success no contena descripcin
SDP, sern usados los parmetros de descripcin de
sesin del mensaje INVITE inicial para la media
SIP
OPTIONS
Este mensaje se enva para consultar las capacidades
de un agente de llamada. Esta es una herramienta
adecuada para determinar qu tipos de media
soporta un usuario remoto antes de realizar una
llamada
BYE
El cliente enva este mensaje al agente de llamada
para terminar la llamada
Un mensaje BYE de la otra parte no es necesario
SIP
CANCEL
Este mtodo cancela un requerimiento en progreso, pero no
tiene efecto sobre una llamada establecida cuando ningn
requerimiento est en progreso
Debe identificar explicitamente la llamada a travs de los
valores Call ID, Call Sequence (Cseq), To and From en el header
SIP
REGISTER
Permite a un cliente registrar la direccin listada en el campo de
header To, con un servidor SIP
Un agente de usuario se puede registrar cuando arranca con un
servidor local enviando un requerimiento REGISTER a la
direccin multicast bien conocida all SIP servers
sip.mcast.net (224.0.1.75)
La registracin puede ser hecha por el usuario o por una tercera
parte en nombre del usuario. Esto ser mostrado en el campo
From
Respuestas SIP
SIP define 6 clases de respuestas a los

mensajes. Cada clase de respuesta usa un
cdigo de un rango
1xx - Mensajes informativos
2xx Respuestas satisfactorias
3xx Respuestas de redireccionamiento
4xx Respuestas de falla de requerimiento
5xx - Respuestas de falla de servidor
6xx - Respuestas de fallas globales
Respuestas SIP
Clase de Cdigo Explicacin

respuesta de
status
Informational 100 Trying (anloga al Call Proceeding
de Q.931)
180 Ringing (anloga al Alerting de
Q.931)
181 Llamada est siendo forwarded
182 Acolada para servicio

Respuestas SIP

respuesta de
status
Success 200 Requerimiento fue ejecutado
satisfactoriamente (OK)
Respuestas SIP

respuesta de
status
Redirection 300 La direccin del requerimiento resolvi en ms de una
eleccin que son retornadas al llamante
301 El usuario llamado se ha movido permanentemente a

la localizacin retornada en el header Contact
302 El usuario llamado se ha movido temporariamente y

puede ser encontrado en la direccin retornada
305 El usuario llamado no puede ser accedido
directamente pero la llamada se puede manejar a
travs de un proxy
380 Servicios alternativos

Respuestas SIP
respuesta de
status
Client 400 Mal requerimiento debido a error de sintaxis
request
failure
401 No autorizado, el usuario requiere autenticacin
402 Se requiere un pago
403 Requerimiento prohibido
404 Usuario no encontrado
405 Mtodo no permitido para el usuario llamado

406 No aceptable
Respuestas SIP
respuesta de
status
Client 407 Autenticacin proxy requerida
request
failure
408 El servidor no puede producir una respuesta dentro del
tiempo requerido por el llamante
409 Hay un conflicto entre el requerimiento y otras
condiciones dentro del server
410 El usuario o servicio requerido se ha ido de este server
y no dej direccin de forwarding
411 El servidor requiere al llamante colocar la longitud del
cuerpo del mensaje en el header
413 El tamao del requerimiento es demasiado largo para
que el servidor lo pueda manejar
Respuestas SIP
respuesta de
status
Client 414 URI requerido demasiado largo
request
failure
415 Tipo de media no soportada
420 El server no comprende la extensin del protocolo SIP
480 Parte llamada est temporariamente no disponible
481 El server recibi un CANCEL para un requerimiento que

no existe o un BYE para una llamada no existente
482 Lazo detectado en ruteo de mensaje
Respuestas SIP

respuesta de
status
Client 483 Los hops requeridos para alcanzar la parte llamada
request excedieron el mximo permitido
failure
484 Direccin incompleta
485 Direccin ambigua para la parte llamada
486 La parte llamada est ya sea ocupada o no desea

tomar la llamada
Respuestas SIP
respuesta de
status
Server 500 Error de server
failures
501 El servicio requerido no est implementado
502 Mala respuesta recibida por el server desde un

gateway u otro server sobre el camino de llamada
hacia el endpoint
503 Servicio temporariamente no disponible
504 El server tuvo time-out mientras acceda a un

gateway
505 Versin SIP no soportada
Respuestas SIP
respuesta de
status
Global 600 La parte llamada est ocupada
failures
603 La parte llamada declina la llamada
604 El usuario llamado no existe en ningn lugar
606 El usuario desea aceptar la llamada pero hay

incompatibilidades en la media requerida
Proceso de comunicacin SIP
Usualmente ocurren 6 pasos:
1. Registrar, iniciar y localizar el usuario
2. Determinar la media a usar
3. Determinar el deseo de la parte llamada para
comunicarse
4. Establecimiento de la llamada
5. Modificacin de la llamada, ej. call transfer
6. Terminacin de la llamada
SIP - Modelo de llamada bsica
Sealizacin directa entre agentes de usuario
Consideremos una llamada hecha por
penny@dflx.com a lucy@remotesysname.com
en nuestro diagrama de referencia
En este primer ejemplo los agentes de usuario
operan directamente y se enva un comando
INVITE desde el originador a la parte llamada
Esto significa que el agente de usuario para el
Endpoint A ha resuelto el nombre del Endpoint
B en una direccin IP a travs de una consulta
DNS
El comando INVITE se enva al nmero de port
UDP bien conocido para SIP (5060) y contiene
Call-ID, Cseq y SDP del formato de media,
adems de informacin de ruteo tal como From,
To y Via
La respuesta de informacin TRYING (100) es
anloga al mensaje CALL PROCEEDING de
Q.931 e indica que la llamada est siendo
ruteada. En los modelos proxy y redirect es
muy til para mantener track del progreso de la
llamada
Cuando la llamada ha alcanzado el endpoint
remoto y el telfono (real o virtual) est
sonando se enva el mensaje RINGING (180),
anlogo al mensaje ALERTING de Q.931
Cuando Lucy atiende se enva un cdigo de
respuesta 200 y el UA de Penny enva el
requerimiento ACK reconociendo la respuesta
satisfactoria al requerimiento INVITE
El ACK puede transportar los parmetros SDP
finales para el tipo de media y formato
sugeridos por el endpoint receptor
Si el ACK no contiene una descripcin SDP, se
usa el SDP original del mensaje INVITE
La combinacin de la respuesta satisfactoria al
INVITE y el siguiente ACK es similar al mensaje
CONNECT de Q.931
Un requerimiento BYE de cualquiera de las
partes termina la llamada
Dado que todos los mensajes se envan sobre
UDP, no hay nada ms para hacer
SIP - Modelo de llamada proxy
SIP - Modelo de llamada proxy
Penny dispone del nombre del servidor SIP de
Lucy y le enva un INVITE indicando
lucy@remotesysname.con en el campo To
El sevidor debe verificar si Lucy est registrada
con l y cual es ubicacin actual
Entonces le pasa el requerimiento INVITE sin
alterar los campos de header excepto
agregando su propio nombre de server en el
campo Via
SIP Modelo de llamada
redireccionada
SIP Modelo de llamada
redireccionada
Se reduce al modelo directo despus que el
server enva una respuesta de redireccin al
INVITE, con cdigo 301 302 indicando que
Lucy puede ser encontrada en la ubicacin
listada en el campo Contact
Entonces Penny cierra su sealizacin con ese
server y enva otro INVITE a la localizacin
retornada en la respuesta de redireccin
Operacin de SIP (1)
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
Operacin de SIP (2)
El ejemplo muestra las funciones bsicas de SIP
Localizacin de un end point
Indicar el deseo de comunicarse
Negociacin de parmetros para establecer la sesin
Terminacin de la sesin una vez establecida
Alice llama a Bob usando un SIP URI de Bob
SIP tambin provee un URI seguro llamado un

SIPS URI, lo que garantiza que se usa
transporte encriptado seguro para llevar todos
los mensajes SIP desde el llamante hasta el
dominio del llamado
Operacin de SIP (3)
SIP se basa sobre un modelo requerimiento-
respuesta como HTTP
Cada transaccin consiste de un requerimiento
que involucra un mtodo particular y por lo
menos una respuesta
Los campos de header son atributos que
proveen informacin adicional sobre un mensaje
Mensaje INVITE (F1 en Fig. 1)
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
Campos de Header (1)
Via
Contiene la direccin (pc33.atlanta.com) en la cual Alice est
esperando recibir respuestas a este requerimiento
Contiene un branch parameter que identifica esta transaccin
To
Contiene un nombre y un SIP URI hacia quien el requerimiento
est originalmente dirigido
From
Contiene un nombre y un SIP URI que indica el originador del
requerimiento
Contiene un tag parameter con un string aleatorio que fue
agregado al URI por el softphone. Se usa para propsitos de
identificacin
Call-ID
Contiene un identificador globalmente nico para esta llamada,
generado por la combinacin de un string aleatorio y el nombre
del host del softphone o la direccin IP
Combinacin de To tag, From tag, Call-ID, define
completamente una relacin SIP entre Alice y Bob
llamada dilogo
CSeq o Command Sequence

Contiene un nmero entero y un nombre de mtodo. El nmero
se incrementa con cada nuevo requerimiento dentro de un
dilogo
Contact
Contiene un SIP URI que representa una ruta directa para
contactar a Alice
Mientras Via indica donde enviar la respuesta, Contact indica
donde enviar requerimientos futuros.
Max-Forwards
Sirve para limitar el nmero de hops que un requerimiento
puede hacer sobre el camino a su destino.
Content-Type
Contiene una descripcin del cuerpo del mensaje.
Content-Length
Contiene la cantidad de bytes del cuerpo del mensaje.
Los detalles de la sesin (tipo de media, codec, tasa,
etc) no son descriptos por SIP sino por un mensaje de
SDP.
Session Description Protocol (1)
El protocolo SDP est definido en la RFC 2327, RFC 3266 y posteriormente en
la RFC 4566 (declara obsoletas a las dos anteriores). La utilizacin conjunta
entre SIP y SDP se define en la RFC 3264. SDP describe la sesin multimedia
que va a ser necesario establecer entre los end points.
Como resultado de la negociacin entre los extremos se acuerdan los
parmetros de la comunicacin relacionados con las siguientes caractersticas:
Direcciones y puertos
Los tipos de Media (video, audio, etc)
El transporte del protocolo (RTP/UDP/IP, H.320, etc)
El formato de la Media (H.261 video, MPEG video, etc)
El mensaje SDP est basado en lneas de texto donde cada lnea representa un
campo. Las lneas comienzan con una letra que identifican al campo seguido
del signo igual (=) y de su valor correspondiente.
campo=valor (algunos campos incluyen subcampos que llevan un orden prefijado)
Los campos son de sesin o de medios, pueden ser obligatorios u
opcionales. Los de sesin van primero.
Si solo se establece una

comunicacin, se utiliza
un solo puerto
v: versin del protocolo

o: Origen, identifica al remitente. Tiene seis subcampos: Nombre de usuario de origen
(remitente), identificador se sesin, versin de la sesin, tipo de red ( IN= Internet),
tipo de direccionamiento ( IP4 o IP6), direccin de origen ( IP o dominio).
s: session name, se utiliza en sesiones multicast
t : time, hora predefinida de comienzo y fin. Si la duracin es indefinida t=0 0
m: media type. Tiene cuatro subcampos; tipo de medio (audio, video, aplicacin,
datos o control), puerto ( utilizado en destino), protocolo de transporte (RTP) y
formato multimedia (incluye lista de formatos por orden de preferencia)
a: Atributo adicional; son de aplicacin a la sesin o al medio individual
SDP define el orden en que deben aparecer los campos.Algunos

estn definidos como obligatorios: v, o, s, t, m
Campos de sesin: v, o, s, i, u, e, p, c, b, t, r, z, k y a
Campos de medio: m, i, c, b, k, a
Existen campos de SDP que no tienen sentido dentro de SIP.
Estos no se incluyen o si son obligatorios no aportan valor a la
informacin. (s, i, u, t, r, z)
otros campos opcionales

c: conexin Tiene tres subcampos, tipo d red, tipo de direccin y direccin de la
conexin. Se refiere al destinatario.
e: email de la persona responsable de la sesion
B: Ancho de banda necesario en kilobits por segundo
k: Cifrado, indica la clave o mecanismo para obtenerla para cifrar y descifrar la
informacin de multimedia.
p: Telfono de la persona responsable de la sesin
Atributos SDP
Procedimiento (1)
Dado que el softphone no conoce la ubicacin
de Bob ni del servidor SIP en el dominio
biloxi.com, el softphone enva el INVITE al
servidor SIP que sirve el dominio de Alice:
atlanta.com. La direccin de este servidor se
podra haber configurado en el softphone de
Alice, podra haber sido descubierta por DHCP,
por ejemplo
La respuesta 100 (Trying) indica que se ha
recibido el INVITE y que el proxy est
trabajando en nombre de Alice para rutear el
INVITE
Procedimiento (2)
Respuestas en SIP usan un cdigo de 3 dgitos
seguido por una frase descriptiva
Esta respuesta contiene el mismo To, From, Call-ID,
CSeq y branch parameter en Via como el INVITE,
esto permite al softphone de Alice correlacionar esta
respuesta con el INVITE enviado
El proxy server atlanta.com localiza el proxy
server biloxi.com, posiblemente haciendo una
bsqueda particular de DNS para encontrar el
servidor SIP que sirve al dominio biloxi.com
Antes de pasar el requerimiento INVITE el
servidor atlanta.com agrega un campo de
header VIA adicional que contiene su propia
direccin
Procedimiento (3)
El proxy server biloxi.com recibe el INVITE,
enva una respuesta 100 (Trying) al proxy
server atlanta.com, consulta una base de datos
genericamente llamada un location service
que contiene la direccin IP actual de Bob
El proxy server biloxi.com proxy agrega otro
campo de header VIA con su propia direccin al
INVITE y lo enva a Bob
La respuesta 180 (Ringing) se puede rutear a
travs de los 2 proxys usando los campos de
header VIA para determinar donde enviar la
respuesta y remover una direccin del top
Mensaje OK (F9 en Fig. 1)
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)

Procedimiento (4)
Los campos de header Via, To, From, Call-ID y
Cseq son copiados del requerimiento INVITE
Hay 3 campos de header Via: uno agregado por
el SIP phone de Alice, uno agregado por el
proxy atlanta.com y uno agregado por el proxy
biloxi.com
El SIP phone de Bob agreg un tag parameter al
campo de header To. Este tag ser incorporado
por ambos end points en el dilogo y ser
incluido en todos los futuros requerimientos y
respuestas de esta llamada
Procedimiento (5)
Adems de DNS y location service usados en
este ejemplo, los proxy servers pueden hacer
decisiones de ruteo flexibles para decidir donde
enviar un requerimiento
Por ejemplo, si el SIP phone de Bob retorna una
respuesta 486 (Busy Here), el proxy server
biloxi.com podra enviar el INVITE al voicemail
server de Bob
Un proxy server puede tambin enviar un
INVITE a varias localizaciones al mismo tiempo.
Este tipo de bsqueda paralela se conoce como
forking
Procedimiento (6)
Finalmente Alice enva un ACK a Bob para
confirmar la recepcin de la respuesta (200
(OK)).
En este ejemplo el ACK se enva directamente
de Alice a Bob. Esto es posible debido a que los
endpoints han aprendido la direccin del otro
partir de los campos de header Contact.
Esto completa el three-way handshake
INVITE/200/ACK usado para establecer sesiones
SIP.
Procedimiento (7)
Durante la sesin ya sea Alice o Bob pueden
decidir cambiar las caractersticas de la sesin
de media enviando un INVITE conteniendo una
nueva descripcin de media
El INVITE referencia el dilogo existente, entonces la
otra parte reconoce que se desea modificar una
sesin existente en vez de establecer una nueva
La otra parte enva un 200 (OK) para aceptar el
cambio y el que lo requiri responde con un
ACK
Si la otra parte no acepta el cambio enva una
respuesta de error tal como 488 (Not Acceptable
Here), que tambin recibe un ACK y se continua
usando las caractersticas previamente negociadas
Procedimiento (8)
Al final de la llamada Bob desconecta primero y
genera un mensaje BYE que es ruteado
directamente al softphone de Alice
Alice confirma la recepcin del BYE con una
respuesta 200 (OK) que termina la transaccin BYE y
la sesin
En algunos casos puede ser til para los proxys
ver todos los mensajes entre los endpoints
durante la duracin de la sesin
Para eso el servidor agrega al INVITE un campo de
header de ruteo: Record-Route con la direccin IP del
proxy. Esta informacin es recibida tanto por el SIP
phone de Bob como por el de Alice, ya que el campo
de header Record-Route es pasado en el 200 (OK)
Registracin (1)
Asocia un particular Contact URI con un SIP
user Address of Record (AOR)
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| 401 Unauthorized F2 |
|<------------------------------|
| REGISTER F3 |
|------------------------------>|
| 200 OK F4 |
|<------------------------------|
| |
Registracin (2)
UAs pueden determinar a qu direccin enviar
registraciones por configuracin, usando el
address-of-record (por ej. el UA para el usuario
"sip:carol@chicago.com" direcciona el
requerimiento REGISTER a "sip:chicago.com "),
por multicast enviando las registraciones a la
direccin multicast bien conocida "all SIP
servers: "sip.mcast.net" (224.0.1.75 for IPv4)
Registracin (3)
Bob enva un requerimiento REGISTER al SIP
server incluyendo la lista de contactos del
usuario
El SIP server solicita autenticacin. Bob ingresa
su user ID y password
El SIP server registra al usuario y enva una
respuesta 200 OK a Bob que incluye la lista de
contactos actual del usuario en los headers
Contact
Campos de header (1)
Request-URI
El dominio del location service para el cual la
registracin es significativa (ej. "sip:chicago.com").
To
Contiene el address of record (SIP URI o SIPS URI)
cuya registracin se debe crear, consultar o modificar
From
Contiene el address-of-record de quien realiza la
registracin. Coincide con el header To excepto si el
requerimiento lo realiza una 3 parte
Call-ID
Todas las registraciones de un UAC deben usar el
mismo valor de Call-ID para las registraciones
enviadas a un particular registrar
Cseq
Un UA debe incrementar el valor en uno en cada
requerimiento REGISTER con el mismo Call-ID
Contact
Requerimientos REGISTER pueden contener un
campo de header Contact con cero o ms valores
conteniendo asociaciones de direcciones
El parmetro "expires indica cuntos segundos
desea el UA que sea vlida la asociacin
Si no se provee este parmetro entonces se usar el
valor del campo de header Expires, pero este sugiere
un intervalo de expiracin para todos los valores del
campo de header Contact que no contienen el
parameter "expires"
Si ninguno de los 2 mecanismos est presente en un
REGISTER entonces el server lo elige
Tipicamente los valores del campo de header
Contact del requerimiento consisten de SIP o SIPS
URIs que identifican un particular endpoint, ej.
"sip:carol@cube2214a.chicago.com"), pero un SIP UA
puede elegir registrar nmeros telefnicos con el tel
URL o direcciones de email con el mailto URL
Detalles de mensaje F1
F1 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0

Via: SIP/2.0/TLS
client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
F2 401 Unauthorized SIP Server -> Bob
SIP/2.0 401 Unauthorized

Via: SIP/2.0/TLS
;received=192.0.2.201
To: Bob <sips:bob@biloxi.example.com>;tag=1410948204
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="atlanta.example.com",
qop="auth",
nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
opaque="", stale=FALSE, algorithm=MD5
Content-Length: 0

Via: SIP/2.0/TLS
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Authorization: Digest username="bob",
realm="atlanta.example.com"
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
uri="sips:ss2.biloxi.example.com",
response="dfe56131d1958046689d83306477ecc"
F4 200 OK SIP Server -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Content-Length: 0
Actualizacin de lista de
contactos
Bob desea actualizar la lista de direcciones
donde el SIP server redirigir o enviar
requerimientos INVITE
Bob SIP Server

| |
| REGISTER F1 |
|------------------------------>|
| 200 OK F2 |
|<------------------------------|
| |

Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
CSeq: 1 REGISTER
Contact: mailto:bob@biloxi.example.com
Authorization: Digest username="bob", realm="atlanta.example.com",
qop="auth", nonce="1cec4341ae6cbe5a359ea9c8e88df84f", opaque="",
response="71ba27c64bd01de719686aa4590d5824"
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS
client.biloxi.example.com:5061;branch=z9hG4bKnashds7;received=
192.0.2.201
To: Bob <sips:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER
Contact: <mailto:bob@biloxi.example.com>;expires=4294967295
Content-Length: 0
Requerimiento de la lista de
contactos actual
El requerimiento REGISTER no contiene headers
de contacto, indicando que se desea consultar la
lista actual de contactos del usuario
Bob SIP Server

| |
| REGISTER F1 |
|------------------------------>|
| 200 OK F2 |
|<------------------------------|
| |

Via:
SIP/2.0/TLSclient.biloxi.example.com:5061;branch=z9hG4bKnashds
7
Max-Forwards: 70
CSeq: 1 REGISTER
Authorization: Digest username="bob",
realm="atlanta.example.com",
nonce="df84f1cec4341ae6cbe5ap359a9c8e88", opaque="",
response="aa7ab4678258377c6f7d4be6087e2f60"
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS
;received=192.0.2.201
To: Bob <sips:bob@biloxi.example.com>;tag=jqoiweu75
CSeq: 1 REGISTER
Contact: <mailto:bob@biloxi.example.com>;expires=4294967295
Content-Length: 0
Removiendo registraciones
Registraciones son soft-state y expiran a menos que
sean refrescadas, pero pueden tambin ser
explicitamente removidas
Un UA requiere la inmediata remocin de una asociacin
especificando un intervalo de expiracin de "0" para esa
direccin de contacto en un requerimiento REGISTER
El REGISTER-specific Contact header field value of "*"
se aplica a todas las registraciones pero no debe ser
usado a menos que el campo de header Expires est
presente con un valor de "0"
Uso del valor de campo de header Contact "*" permite a
un UA remover todas las asociaciones con una address-
of-record sin conocer sus valores precisos
Cancelacin de registracin
Bob SIP Server

| |
| REGISTER F1 |
|------------------------------>|
| 200 OK F2 |
|<------------------------------|
| |

Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
CSeq: 1 REGISTER
Expires: 0
Contact: *
Authorization: Digest username="bob", realm="atlanta.example.com",
nonce="88df84f1cac4341aea9c8ee6cbe5a359", opaque="",
response="ff0437c51696f9a76244f0cf1dbabbea"
Content-Length: 0
Detalle de mensaje F2
SIP/2.0 200 OK
Via: SIP/2.0/TLS
;received=192.0.2.201
To: Bob <sips:bob@biloxi.example.com>;tag=1418nmdsrf
CSeq: 1 REGISTER
Content-Length: 0
H.323
Conceptos
H.323 - Componentes - Gateway
Anlisis conceptual del escenario
H323 - Componentes
La primera versin de H.323 se public en 1996 con el objeto de permitir
las comunicaciones de voz y multimedia. Es completamente compatible con
la telefona tradicional. Su funcionamiento se basa en cuatro elementos:
Terminal, Gateway, Gatekeeper y Unidad de control multipunto
Gatekeeper
Red IP
Terminal H.323
PSTN
Gateway
Funciones Gateway
Provee la ruta de conexin entre el punto terminal de la red de
rea local y la red de circuitos conmutados.
Sealizacin de Paquetes
Sealizacin de Circuitos
Terminacin de Medios de Paquetes
Terminacin de Medios de Circuitos
Control de Conexin y Traduccin de Protocolo
H323 Componentes (2)
H.323 - Componentes - Gatekeeper
Gatekeeper
Terminal H.323
PSTN
Gateway
Red IP
Funciones del Gatekeeper

Traduccin de direccin Sealizacin de control de llamadas para las
Control de Admisin - terminales
autoriza acceso a la red Autorizacin de Llamadas
Control ancho de banda Administracin de Ancho de Banda
Administracin de Zona Servicios de Directorio
H323 Componentes (1)
TERMINALES
Endpoint con capacidad de recibir o generar llamadas mediante
H323.
MCUs
Endpoint que soporta conferencia entre 3 o mas endpoints, puede
ser un equipo stand-alone o encontrarse integrado dentro de un
gateway, gatekeeper o terminal.
H.323 - SUITE
H323 Suite de Protocolos para aplicaciones de multimedia (1)
Conjunto de protocolos H.323 desde el punto de vista del terminal
H.323 - Funciones de cada protocolo
H323 Suite de Protocolos para aplicaciones de multimedia (2)
H.225.0 /Q.931 Se utiliza para configuracin y sealizacin de la
llamada.
H.225/ RAS Registration, Admission, and Status. Usado entre los

Endpoint yel gatekeeper para:
Permitir al Gatekeeper administrar los Endpoint
Permitir al Endpoint solicitar admisin para realizar una llamada.
Permite que el gatekeeper brinde el servicio de resolucin de
direcciones a los endpoints.
H.245 Protocolo de control, se utiliza entre extremos de la conexin

para negociar capacidades (por ejemplo, Codecs soportados) apertura y
cierre de canales lgicos, mensajes de control de flujo etc.
Negocia el uso del canal y las caractersticas de la comunicacin
T.120 Protocolo para establecer aplicaciones interactivas como una

conferencias multimedia o en el caso de una pizarra.
Anlisis conceptual del escenario H.323 - Bsqueda de Gateway
H323 Establecimieno de una llamada

Cuando un Endpoint se conecta a la red IP, y esta configurado para funcionar de
esta manera, busca un Gatekeeper por medio del cual establecer las llamadas. El
gatekeeper puede o no admitir al usuario considerando una o varias razones
administrativas o de seguridad.
GCF
GRQ GRJ
Gatekeeper Request Gatekeeper Reject Gatekeeper Confirm
Pasos en la conexin H.323:

Establecer la conexin utilizando H.225.0 ( sealizacin de la llamada)
Negociar los parmetros del intercambio de informacin multimedia utilizando el
protocolo H.245
Llevar a cabo la conversacin.Cada terminal utilizar el codec y la configuracin
acordada en la negociacin anterior
Dada por terminada la comunicacin, se liberan los recursos implicados(H.245 y
H.225.0)
H.323 - Establecimiento de una llamada
H323 Establecimieno de una llamada (1)
A B
GK RRQ: Registration Request
RRQ RRQ RCF: Registration Confirm
RAS RCF RCF RRJ: RegistrationReject
ARQ
RAS ACF El endpoint enva un pedido de
registro al Gatekeeper, si es
Setup
aceptado en el futuro podr
H.225 Call Proceeding
utilizar dicho Gatekeeper para
ARQ cursar sus llamadas.
ACF RAS
Alerting
H.225 Connect
Terminal Capability Set

Terminal Capability Ack
H.245
Open Logical Channel
RTP voice packet

RTP RTP voice packet
A B
GK
RRQ RRQ
RAS RCF RCF
ARQ: AdmissionRequest
ARQ
RAS ACF ACF: AdmissionConfirm
Setup ARJ: AdmissionReject
H.225 Call
Proceeding
ARQ
Le solicita al gatekeeper que le
ACF RAS permita ingresar a la red de
Alerting paquetes.
H.225 Connect

H.245
RTP voice packet

H323 Establecimieno de- Establecimiento
H.323 una llamadade (3)
una llamada
A B
GK
RRQ RRQ
RAS RCF RCF
ARQ
RAS ACF
SETUP
Setup El abonado llamante le informa
H.225 Call Proceeding al abonado llamado su
ARQ intencin de establecer una
ACF RAS conexin.
Alerting
H.225 Connect CALL PROCEEDING
Terminal Capability Set El abonado B para indicarle al
Terminal Capability Ack abonado A que su pedido de
H.245 iniciar una conexin ha sido
Open Logical Channel aceptado y esta en curso.
RTP voice packet
A B
GK
RRQ RRQ
RAS RCF RCF
ARQ
RAS ACF
Setup
ARQ
ACF RAS
ALERTING
Alerting
H.225 Connect Este mensaje se enva al
llamante para indicarle que el
Terminal Capability Set telfono B esta sonando.
H.245 CONNECT
Open Logical Channel El abonado B contesto la
llamada.
RTP voice packet
A B
GK
RRQ RRQ
RAS RCF RCF
ARQ
RAS ACF
Setup
ARQ
ACF RAS
Alerting
H.225 Connect
Terminal Capability Set Negociacin de capacidades y

Terminal Capability Ack apertura del canal lgico para
H.245
Open Logical Channel comenzar el intercambio de
Open Logical Channel datos multimedia.
RTP voice packet
H323 Establecimieno de- una
H.323 llamadade
Establecimiento (6)
una llamada
A B
GK
RRQ RRQ
RAS RCF RCF
ARQ
RAS ACF
Setup
ARQ
ACF RAS
Alerting
H.225 Connect

H.245
RTP voice packet Intercambio de datos

RTP RTP voice packet multimedia
H.323 - Terminacin de una llamada
A B
GK
RRQ RRQ
End Session
H.245 End Session
Libero los canales RTP y RTCP
Release Complete
H.225
DRQ DRQ
RAS DCF DCF RAS
A B
GK
RRQ RRQ
End Session
H.245 End Session
Release Complete Libero la conexin en el plano

H.225
de sealizacin.
DRQ DRQ
RAS DCF DCF RAS
A B
GK
RRQ RRQ
End Session
H.245 End Session
Release Complete
H.225
DRQ DRQ DRQ: DisengageRequest

RAS DCF DCF RAS DCF: DisengageConfirm
DRJ: DisengageReject
Los terminales le informan al o

los Gatekeepers la terminacin
de la comunicacin.
H.323 - Modelos de Sealizacin

El modelo determina que protocolos pasan por el
gatekeeper, y cuales viajan directamente entre los Endpoints.
En el mensaje Admission Request (ARQ) se incluye la
informacin del modelo de la llamada. Es decir si la llamada
se har directamente entre terminales o si el gatekeeper har
de intermediario
Dependiendo de la cantidad de protocolos el gatekeeper

tendr mas o menos carga y responsabilidad en la red.
Los datos multimedia nunca pasan por el gatekeeper.

H.323 - Sealizacin Directa entre EndPoints

H.323 - Sealizacin por Gatekeeper (Q.931)

H.323 - Sealizacin por Gatekeeper (Q.931/H.245)
H323 Escenario Lan / Wan

H.323 - Sealizacin por Gatekeeper (Q.931/H.245)
H323 Escenario Interzona

Modulo 1 Sip Ucb - 2017

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modulo 1 Sip Ucb - 2017

Cargado por

Copyright:

Formatos disponibles

SIP

Prof. Mgtr. Ing. Ral Gardella

Location service: se usa por un SIP redirect o

Registrar server: un servidor que acepta requerimientos

2) Servicios de localizacin de usuarios: usuarios

SIP usa URIs (uniform resource identifiers)

Como los otros protocolos de sealizacin, SIP

SIP define 6 clases de respuestas a los

Clase de Cdigo Explicacin

182 Acolada para servicio

Clase de Cdigo Explicacin

Clase de Cdigo Explicacin

301 El usuario llamado se ha movido permanentemente a

302 El usuario llamado se ha movido temporariamente y

380 Servicios alternativos

404 Usuario no encontrado

405 Mtodo no permitido para el usuario llamado

420 El server no comprende la extensin del protocolo SIP

480 Parte llamada est temporariamente no disponible

481 El server recibi un CANCEL para un requerimiento que

Clase de Cdigo Explicacin

485 Direccin ambigua para la parte llamada

486 La parte llamada est ya sea ocupada o no desea

501 El servicio requerido no est implementado

502 Mala respuesta recibida por el server desde un

504 El server tuvo time-out mientras acceda a un

603 La parte llamada declina la llamada

604 El usuario llamado no existe en ningn lugar

606 El usuario desea aceptar la llamada pero hay

Alice llama a Bob usando un SIP URI de Bob

SIP tambin provee un URI seguro llamado un

CSeq o Command Sequence

Si solo se establece una

v: versin del protocolo

SDP define el orden en que deben aparecer los campos.Algunos

otros campos opcionales

(Bob's SDP not shown)

REGISTER sips:ss2.biloxi.example.com SIP/2.0

SIP/2.0 401 Unauthorized

REGISTER sips:ss2.biloxi.example.com SIP/2.0

Bob SIP Server

REGISTER sips:ss2.biloxi.example.com SIP/2.0

Bob SIP Server

REGISTER sips:ss2.biloxi.example.com SIP/2.0

Bob SIP Server

REGISTER sips:ss2.biloxi.example.com SIP/2.0

Funciones del Gatekeeper

H.225/ RAS Registration, Admission, and Status. Usado entre los

H.245 Protocolo de control, se utiliza entre extremos de la conexin

T.120 Protocolo para establecer aplicaciones interactivas como una

H323 Establecimieno de una llamada

Gatekeeper Request Gatekeeper Reject Gatekeeper Confirm

Pasos en la conexin H.323:

Terminal Capability Set

RTP voice packet

Terminal Capability Set

RTP voice packet

Terminal Capability Set Negociacin de capacidades y

Terminal Capability Set

RTP voice packet Intercambio de datos

Release Complete Libero la conexin en el plano

DRQ DRQ DRQ: DisengageRequest

Los terminales le informan al o