Curso Protocolo SIP

Protocolo SIP
Session Initiation Protocol

AECT-2014
Presentación
NOMBRE
ROLE/POSICIÓN
ESPECTATIVAS
1
Consideraciones
Horario de Clases
Dias
Lunes, Martes, Miércoles y Jueves
Horario
18:30 a 21:30 hrs.
Evaluaciones
4 Parciales (40%)
1 Final (60%)
2
Temario
01 Introducción
02 Protocolos de Señalización
03 Protocolo SIP
04 Servicios
05 Laboratorios
3
01
Introducción
Razón Social: Telefónica

Área: Lorem ipsum
4
Visión General y Evolución de la Red PSTN
5
PSTN v/s NGN
6
Nuevos Servicios en NGN
7
Componentes Plataforma VoIP
Application Server (AS): En este equipo se encuentra la
lógica de Servicio. En el residen las aplicaciones que
interactúan con el usuario.
Network Server (NS): Lógica de Ruteo y Control, definición

de recursos de red.
Media Server (MS): Recursos de Multimedia, IVR y Audio

Conferencia.
Conferencing Server (CS): Permite realizar audio

conferencia para más de 3 usuarios.
E-Mail Server (EMS): Permite Almacenar los mensajes de

voz para las casillas de los usuarios.
Web Server (WS): Permite las conexiones vía Web
8
02
Protocolos
Protocolos de Señalización

Área: Lorem ipsum
9
Protocolos de Señalización
VoIP
10
Protocolos de Señalización Voz
Protocolo Descripción
H.323 Protocolo estándar ITU para conferencia
interactiva, evolucionado del estándar ISDN H.320,
flexible y complejo
MGCP Estándar IETF para los gateway de control PSTN,
control de dispositivos.
SCCP o Protocolo propietario de Cisco utilizado entre Cisco
Skinny Unified Communications Manager y teléfonos
Cisco VoIP
SIP Protocolo de señalización y control para el
establecimiento, mantenimiento y terminación
de sesiones multimedia con uno o más
participantes.
IETF RFC 2543-1999; RFC 3261-2002.
11
H.323
En él se describe una infraestructura de terminales, componentes de
control común, servicios y protocolos que se utilizan para las
comunicaciones multimedia (voz, vídeo y datos) a través de una red IP.
Protocolo peer-to-peer (dispositivo final inicia las sesiones).
Utilizado por gateways, gatekeepers, o cliente de conferencia tripartita
H.323, especialmente terminales de video (Cisco, Polycom, etc.)
Ventajas de los gateways H.323
Dial plan, traducciones, configuraciones de ruteo de las llamadas, ISDN, Fax.
H.323 incluye los siguientes protocolos
H.225 call signaling
H.225 Registration, Admission, and Status (RAS)
H.245 control signaling
Audio codecs (G.711, G.722 (64, 56 y 48 kbps), G.723.1 (5,3 y 6,3
kbps), G.728 (16 kbps) y G-729 (8 kbps))
Video códec (H.261)
12
Componentes de Red H.323
4Terminal H.323
4Unidad de control MCU
4Gateway
4Gatekeeper
4Conversión
de señalización
de llamada
4Conversión
de señalización
de medios
4Conversión
de medios
4Traducción de
alias H.323 en
direcciones de red
4Control de
admisiones y ancho
de banda
4Proporcionan
administración de
políticas
13
MGCP - (Media Gateway Control Protocol)
o IETF RFC 3435 que deja obsoleto a RFC 2705.
o Arquitectura definida en RFC 2805.
o Protocolo Cliente/Servidor que permite a un dispositivo de
control de llamadas, tomar el control de un puerto específico
sobre un gateway (UDP puerta 2427) puerta 2727 usado
para envío de mensaje a los agentes de llamadas.
o Para que una interacción MGCP tenga lugar con Cisco
Unified Communications Manager, tiene que asegurarse de
que el software Cisco IOS o del sistema operativo Cisco
Catalyst sea compatible con Cisco Unified Communications
Manager.
o Soporta la señalización QSIG.
o Permite el control remoto de varios dispositivos.
o Protocolo de estimulo (no funcionan solos).
o Direccionamiento del numero telefónico basado en la E.164.
o Usa IETF SDP.
14
MGCP - (Media Gateway Control Protocol)
Call Agent Cisco Unified

Gateway Voz (MGCP) Communications
Cisco Manager
PRI PRI
IP PSTN
Residential Gateway Trunking Gateway
* Conexión de teléfonos * Conexión de canales

POTS a una red IP PSTN a una red IP
FXS = Foreign Exchange Station
15
SCCP - (Skinny Client Control Protocol)
Protocolo Señalización Skinny

Protocolo Señalización Skinny
CCM
IP Phone IP Phone
Parte A Parte B
El cliente
Skinny usa
TCP/IP para
transmitir y
recibir
llamadas.
Señalización Real-Time Transport Protocol
(RTP) Para el audio
utiliza RTP,
Es un protocolo propietario de Cisco. UDP e IP.
Es el protocolo por defecto para terminales con el Los mensajes
servidor Cisco Call Manager PBX que es el similar a Skinny son
Asterisk PBX. transmitidos
sobre TCP y
Usado entre el Cisco Call Manager (CCM) y teléfonos IP usa el puerto
Cisco 2000.
16
03
Protocolos
Protocolo de Señalización SIP

Área: Lorem ipsum
17
Protocolo SIP
RFC-3261
18
Que es el Protocolo SIP?
El Session Initiation Protocol (SIP) es un protocolo de

señalización que controla una iniciación, maneja y termina
una sesión multimedia (voz y video) sobre una red de
paquetes.
Esta basado sobre una arquitectura cliente-servidor, en el

cual el cliente inicia un llamado y el servidor responde el
llamado.
IETF RFC 3261.
IERF: Internet Engineering Task Force
RFC: Requests for Comments
19
Fundamentos SIP
RFC-3261.
Protocolo simple extensible.
Basado en texto ASCII
Utiliza el juego de caracteres UTF-8 (RFC-2279 un formato
de transformación de ISO 10646).
Protocolo peer-to-peer.
Crea, modifica, y termina sesiones con uno o mas
participantes.
Aprovecha varios estándares: RTP, RTCP, HTTP, SDP, DNS,
SAP, MGCP y RTSP.
Direccionamiento E.164
Correo electrónico, o registro del servicio DNS (SIP URI RFC-
2396) (Uniform Resource Identifiers)
20
Fundamentos SIP (Cont.)
SIP provee las capacidades:
Determina la localización del punto final del destino.
Determina la capacidad de la media del punto final del

destino.
Determina la disponibilidad del punto final del destino.
Establece una sesión entre el origen y el punto final del

destino.
Maneja la transferencia y terminación de llamados
21
Funcionalidad SIP
User Location
Capacidad de descubrir la localización del usuario final con el
propósito de establecer una sesión.
User Capabilities
Determina la capacidad del medio del dispositivo en una sesión
establecida.
User Availability
Determina la tasación del usuario final.
Session Setup
Establece los parámetros de sesiones de las partes involucradas
en una sesión.
Session Handling
Habilita la modificación, transferencia y terminación de una
sesión activa.
22
Como Trabaja SIP?
El usuario se identifica por una dirección SIP única.
sip:userID@gateway.com
Los usuarios se registran con un Servidor de Registro.
Usando ellos la dirección SIP asignada.
Nota
Una dirección E.164 es un numero telefónico con dígitos decimales
que únicamente indica el punto de terminación de una red publica. El
numero contiene la información necesaria para encaminar la llamada
al punto final.
-->REGISTER sip:10.22.16.35:5060;transport=UDP SIP/2.0
From: sip:228645049@gtd.cl:5060
To: <sip:228645049@gtd.cl:5060>
23
Como Trabaja SIP? (cont.)
Cuando el usuario inicia un llamado, una petición SIP es enviada
al servidor SIP (PBX-IP, Plataforma, etc).
<--INVITE sip:228645049@10.160.144.137:5060 SIP/2.0

From: <sip:226912240@172.25.210.11;user=phone>
To: "228645049 56"<sip:228645049@gtd.cl>
La localización del usuario final puede ser dinámicamente

registrada con el servidor SIP.
El servidor de Localización puede usar uno o mas protocolos, para

ubicar al usuario final (Finger, rwhois, LDAP)
24
Direcciones SIP
Nombre de dominio completo
sip:jdoe@cisco.com
Direcciones E.164
sip:14085551234@gateway.com; user=phone
Direcciones Mixtas
sip:14085551234; password=changeme@10.1.1.1
sip:jdoe@10.1.1.1
25
Por qué SIP?
Ventajas de los gateways SIP
Configuración del Dial-plan directamente sobre el gateway.
Traducciones definidas por el gateway.
Soporte avanzado para la integración de sistemas de otros

fabricantes de telefonía.
Interoperabilidad con gateways de voz de otros fabricantes.
Soporta dispositivos finales de otros fabricantes (teléfonos SIP)
26
Arquitectura SIP
SIP Proxy,
(UAS) Register, (UAS)
Location y
Redirect
Servers
SIP
SIP SIP
PSTN
RTP
E1
o
PRI
Usuarios
Agentes SIP Legacy
(UAC) PBX
27
Entidades SIP (1)
SIP es un protocolo peer-to-peer.
El peer en una sesión se llaman agentes de usuario. Un agente de
usuario puede funcionar en una de estas dos funciones:
Cliente agente de usuario (UAC): Una aplicación cliente que inicia

una petición SIP.
Servidor de agente de usuario (UAS): Una aplicación de servidor que

hace contacto con el usuario cuando una invitación SIP
es recibido y a continuación, devuelve una respuesta en nombre del
usuario a la invitación originador.
Desde un punto de vista arquitectónico, los componentes físicos de una

red SIP se agrupan en estas dos categorías:
28
Entidades SIP (2)
Clientes (endpoints)
Phones : Un acto de telefonía IP como un UAS o UAC de

forma sesión por sesión.
Softphone, gateway y teléfonos IP, SIP inician peticiones

SIP y responden a estas peticiones.
Softphone y teléfonos IP no son configurados sobre los

gateways.
29
Entidades SIP (3)
Clientes (endpoints)
Gateways: Un gateway actúa como UAS o UAC y

proporciona soporte de control de llamadas.
Los gateways proporcionan muchos servicios, siendo los
más común de una función de traducción entre los puntos
finales de conferencia SIP y otros tipos de terminales.
Esta función incluye la traducción entre los formatos de
transmisión y entre los procedimientos de comunicaciones.
Una puerta de enlace también se traduce entre las señales
de audio y vídeo y realiza el establecimiento de llamada y la
limpieza tanto en el lado de IP y la red de conmutación de
circuitos lateral (SCN: Switched Circuit Network)
30
Entidades SIP (4)
Server
Servidor Proxy
Componente intermedio que recibe solicitudes SIP de un
cliente, y luego reenvía las solicitudes en nombre del cliente
al siguiente servidor SIP en la red.
El siguiente servidor puede ser otro servidor proxy o un UAS.
Los servidores proxy pueden proporcionar funciones como:
Autenticación
Autorización.
Control de acceso a la red.
Enrutamiento.
Transmisiones de petición fiables
Seguridad.
31
Entidades SIP (5)
Server
Servidor de Redirección
Proporciona al cliente información sobre el siguiente salto

o saltos que un mensaje debe tomar y luego el cliente
contacta con el servidor del próximo salto o UAS
directamente.
La UA vuelve a dirigir la invitación para el servidor

identificado mediante la redirección servidor.
El servidor puede ser otro servidor de red o un UA.
32
Entidades SIP (6)
Server
Servidor de Registro
Recibe las solicitudes de los agente de usuario SIP que

reside en dicho terminal y envía una petición con el
método REGISTER a un Servidor de Registro, informando
a qué dirección física debe asociarse la dirección lógica
del usuario. El servidor de registro realiza entonces dicha
asociación (denominada binding). Esta asociación tiene
un período de vigencia y si no es renovada, caduca
Servidores Registro a menudo se encuentran cerca o

incluso emplazamiento común con otros servidores de
red, lo más a menudo un servidor de localización.
33
Entidades SIP (7)
Server
Servidor de Localización
Una abstracción de un servicio que proporciona servicios de
resolución de direcciones SIP proxy o redirigir los servidores.
Incorpora mecanismos para resolver las direcciones.
Estos mecanismos pueden incluir una base de datos de
registros o el acceso a herramientas de resolución de uso
común, tales como el protocolo Finger, rwhois, LDAP o
mecanismos dependientes del sistema de funcionamiento.
34
Entidades SIP (8)
B2BUA
Un B2BUA es un tipo de UA que recibe requerimientos SIP, los

reformula y luego los envía cómo nuevos requerimientos.
From.
Vía.
Contact.
Call-ID.
SDP.
En este sentido un B2BUA actúa cómo un proxy SIP, pero NO
sigue sus reglas de enrutamiento.
Se pueden utilizar para servicios de anonimato, evitando que
dos UA involucrados en una sesión SIP puedan aprender el
uno del otro.
35
Estructura Servidores SIP
Nota: Además, los servidores SIP pueden interactuar

con otros servicios de aplicaciones, tales como
servidores LDAP, servidores de localización, una
aplicación de base de datos, o una aplicación de
lenguaje de marcado extensible (XML). Estos
servicios de aplicaciones proporcionan servicios de
back-end, tales como directorios, servicios de
autenticación y facturación
36
Modelo SIP
Cliente: Lado que envía una petición.

Ej.- teléfono SIP o pasarela que inicia una sesión.
Servidor: Lado que responde a una petición recibida.

Ej.- teléfono SIP o pasarela destino.
Transacción: petición + [respuesta (s) provisional (es)] + respuesta

final
37
Petición SIP (Request)
Message SIP
Method
Request-URI
User Part
Host Part
From
To
Cseq
Via
Contact
Session Description Protocol Version (v)

Owner / Creator, Session Id (o)
Session Name (s)
Connection Information (c)
Time Description, active time (t)
Media Description, name and address (m)
Media Attribute (a)
38
Request/Request Line
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Method: This specification defines six methods: REGISTER for registering

contact information, INVITE, ACK, and CANCEL for setting up sessions,
BYE for terminating sessions, and OPTIONS for querying servers about
their capabilities. SIP extensions, documented in standards track RFCs,
may define additional methods.
Request-URI: The Request-URI is a SIP or SIPS URI or a general URI (RFC

2396). It indicates the user or service to which this request is being
addressed. The Request-URI MUST NOT contain unescaped spaces or
control characters and MUST NOT be enclosed in "<>".
SIP elements MAY support Request-URIs with schemes other than "sip"
and "sips", for example the "tel" URI scheme of RFC 2806.
39
Request/Request Line (cont.)
Request-Line = Method SP Request-URI SP SIP-Version CRLF
SIP-Version: Both request and response messages include the

version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and
HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance
requirements, and upgrading of version numbers. To be compliant with
this specification, applications sending SIP messages MUST include a SIP-
Version of "SIP/2.0". The SIP-Version string is case-insensitive, but
implementations MUST send upper-case.
Unlike HTTP/1.1, SIP treats the version number as a literal string. In
practice, this should make no difference.
40
Request/Request Line (cont.)
41
Request/Message Header
42
Definiciones RFC-3261
Encabezado Función
Vía Contiene la dirección en la que USERSIP esta esperando
recibir respuesta a una petición. También contiene un
parámetro branch que identifica esta transacción
From Contiene también un nombre para mostrar ( Alice ) y un
SIP o SIPS URI ( sip: alice@atlanta.com ) que indican el
autor de la petición. Este campo de encabezado también
tiene un parámetro de la etiqueta que contiene una cadena
aleatoria (1928301774) que se ha añadido a la URI por el
softphone . Se utiliza para propósitos de identificación.
43
Definiciones RFC-3261 (cont.)
Encabezado Función
To Contiene un nombre para mostrar (Bob ) y un SIP o SIPS
URI ( sip: bob@biloxi.com ) hacia el cual la solicitud fue
originalmente dirigido. Los nombres para mostrar se
describen en el RFC 2822 .
Caller-ID Contiene un identificador único global para la presente
convocatoria, generado por la combinación de una
cadena aleatoria y el softphone de nombre de host o la
dirección IP . La combinación de la etiqueta To, From, y
Call- ID define completamente una relación SIP peer-to –
peer entre Alice y Bob y se conoce como un cuadro de
diálogo
44
Encabezado Función
Cseq o Contiene un entero y un método de nombre. El número
Secuencia de CSeq se incrementa para cada nueva solicitud dentro de
Comandos un cuadro de diálogo y es un número de secuencia
tradicional
Encabezado Función
User Agent Contiene el agente cliente que realiza la comunicación
Expire Define el tiempo de registro (3600 seg.)
45
Encabezado Función
Contac Contiene un URI de SIP o SIPS que representa una ruta
directa a contacto Alice , generalmente compuesto por un
nombre de usuario en un Full Qualified Doman Name (
FQDN ). Si bien se prefiere un FQDN , muchos sistemas
finales no han registrado nombres de dominio, se
permiten las direcciones IP. Mientras que el campo de
encabezado Vía le dice a otros elementos a dónde enviar
el respuesta, el campo de cabecera de Contact indica
otros elementos donde enviar solicitudes futuras.
46
Encabezado Función
Max-Forwards Sirve para limitar el número de saltos que puede
hacer una solicitud en el camino a su destino . Se
compone de un número entero que se disminuye en
uno en cada salto
Content-Type Contiene una descripción del cuerpo del mensaje ( no
mostrada )
Content-Length Contiene un contador de octeto ( byte) del cuerpo del
mensaje.
47
Peticiones SIP
Method Description
Usado con el fin de establecer una sesión entre UAs.
INVITE corresponde al mensaje ISUP IAM o al mensaje
INVITE 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 serán intercambiados (voz, video,...).
Cuando un UA que emitió el método SIP INVITE recibe una
respuesta final a la invitación (ejemplo : 200 OK), el
ACK
confirma la recepción de esta respuesta por medio de un
método “ACK”.
Permite la liberación de una sesión anteriormente
establecida.
Corresponde al mensaje RELEASE de los protocolos ISUP y
BYE
Q.931.
Un mensaje BYE puede ser emitido por el que genera la
llamada o el que la recibe.
48
Peticiones SIP (cont.)
Method Description
Es utilizado para pedir el abandono de la llamada en curso
pero no tiene ningún efecto sobre una llamada ya aceptada.
CANCEL
De hecho, solo el método “BYE” puede terminar una
llamada establecida.
Es utilizado para interrogar las capacidades y el estado de
un User Agent o de un servidor .
OPTIONS La respuesta contiene sus capacidades (ejemplo: tipo de
media siendo soportado, idioma soportado) o el hecho de
que el UA sea indisponible.
Es usado por una UA con el fin de indicar al Registrar la
correspondencia entre su Dirección SIP lógica
REGISTER
(usuario@dominio) y su dirección de contacto física (ejemplo
: dirección IP).
49
Peticiones SIP (cont.)
Method Description
Usado como señalización en medio del llamado (DTMF,
INFO
hook-flash, etc.)
REFER Usado para transferencia de llamadas
Utilizado por un Agente de Usuario para establecer una

SUBSCRIBE
suscripción con el fin de recibir notificaciones
Utilizado por un Agente de Usuario para transmitir
NOTIFY información acerca de la ocurrencia de un evento en
particular (tal como MWI)
Se utiliza para acusar recibo de las respuestas
PRACK
provisionales fiables transportadas (1xx)
UPDATE Usado para indicar el estado de una sesión
50
Request/Message Body
51
Respuesta SIP (Response)
SIP Version
Status Code
Reason Phrase
Accept-Language
Via
From
To
Cseq
Session Description Protocol Version (v)

Owner / Creator, Session Id (o)
Session Name (s)
Connection Information (c)
Time Description, active time (t)
Media Description, name and address (m)
Media Attribute (a)
52
Response/Status Line
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
The Status-Code is a 3-digit integer result code that indicates the

outcome of an attempt to understand and satisfy a request. The Reason-
Phrase is intended to give a short textual description of the Status-Code.
The Status-Code is intended for use by automata, whereas the Reason-
Phrase is intended for the human user. A client is not required to
examine or display the Reason-Phrase.
While this specification suggests specific wording for the reason phrase,
implementations MAY choose other text, for example, in the language
indicated in the Accept-Language header field of the request.
53
Response/Status Line
54
Respuestas SIP
Informational Redirection
Indica el estado de la llamada Server ha devuelto posibles
antes de completar ubicaciones. El cliente debe
100 Trying reintentar petición
otro servidor.
180 Ringing
300 Multiple Choices
181 Call is being forwarded
301 Moved Permanently
182 Call Queued
302 Moved Temporarily
183 Session Progress
380 Alternative Service
Success
Peticiones logradas
200 OK
202 Accepted
55
Respuestas SIP (cont.)
Client Errors
La solicitud ha fallado debido a un error por parte del cliente.
El cliente puede volver a intentar la
solicitar reformulando la respuesta.
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method not Allowed
407 Proxy Authentication Required
415 Unsupported Media
486 Busy Here
56
Respuestas SIP (cont.)
Server Failure
La solicitud ha fallado debido a
un error del servidor. La
solicitud puede ser analizada en
otro servidor.
500 Server Internal Error Global Failure
501 Not Implemented La solicitud ha fallado y no debe
502 Bad Gateway ser analizada de nuevo en este u
otro servidor.
503 Service Unavailable
600 Busy Everywhere
603 Decline
604 Doesn’t Exist Anywhere
606 Not Acceptable
57
Response/Message Header
58
Donde esta SIP?
SDP Codecs
Application RSTP SIP RTP DNS
Network TCP UDP
Network IP
Physical / Data Link Ethernet
59
¿Que Protocolos son utilizados para VoIP?
Facilidades Necesidad TCP UDP RTP

de la voz
Fiabilidad No Si No No
Reordenamiento Si Si No Si
Sellado de Si No No Si
tiempo
Multiplexión Si Si Si No
60
Fiabilidad
TCP orientado a la conexión.
Para el transporte de la voz RTP y UDP también están
orientados a la conexión.
Reordenamiento
En las redes IP los paquetes pueden arribar en diferente
orden.
Con RTP llegan en orden correcto.
61
Time-stamp (sellado de tiempo)
Se debe conocer el tiempo relativo en que los paquetes son
transmitidos.
El paquete es correctamente reordenado.
El paquete puede tener un apropiado delay insertado entre
paquetes.
Multiplexión
Manejo de múltiples llamados.
Manejo de puertas puertas UDP (16.384 a 32.767)
62
Protocolos de Transmisión de Media
o Real-Time Transport Protocol
o Ofrece el actual flujo de audio y video sobre la red.
o Real-Time transport Control protocol

o Proporciona la información de control fuera de banda
para un flujo RTP.
o cRTP
o Comprime las cabeceras IP/UDP/RTP sobre enlaces
seriales de baja velocidad.
o SRTP
o Proporciona la encriptación, mensajes de autenticación y
la integridad y protección de repetición de los datos RTP
63
Real-time Transport Protocol (RTP)
IETF RFC 3550
Proporciona funciones de red de extremo a extremo y servicios de
entrega en caso de retraso sensible, dato en tiempo real, tal como
voz y video.
Se ejecuta en la parte superior de UDP
Funciona bien con la cola para trafico de voz sobre otros tráficos.
Incluye servicios:
Identificación de payload-type
Secuencia numérica
Time stamping
Monitoreo de la entrega
64
Real-time Transport Protocol (RTP)
65
Real-Time Transport Control Protocol
(RTCP)
RFC 1889, 3550
Provee control de la información fuera de banda para un flujo
RTP.
Utilizado para reportes de QoS.
Monitorea la calidad de la distribución de datos y provee control
de la información.
Proporciona información sobre las condiciones actuales de la red.
Permite acogida que participe en una sesión de RTP para el
intercambio de información sobre la supervisión y el control de la
sesión.
Proporciona un flujo separado de RTP para uso de transporte
UDP.
66
Compresión RTP
RFCs
RFC 2508, compresión de las cabeceras IP/UDP/RTP, para
enlace seriales de baja velocidad.
RFC 2509, compresión de la cabeceras IP sobre PPP.
CRTP mejorado.
RFC 3545, mejora la compresión RTP (CRTP) para enlaces con
alto retardo, perdida de paquetes y reordenamiento.
Comprime las cabeceras de 40 byte a aproximadamente 2 a 4
bytes.
67
Compresión RTP (cont.)
68
Seguridad RTP
RFC 3711
Proporciona.
Encriptación
Advanced Encryption Standard (AES)
Mensajes de integridad y autenticación
Hashed Message Authentication Code-Secure Hash
Algorithm I (HMAC-SHA-I) RFC 2104
Protección de repetición (sin desincriptación)
69
Seguridad RTP (cont.)
70
Protocolo RTP
RFC-3550
71
Stack de Protocolos VoIP
VoIP application
Signaling Speech Application
SDP SIP RTP RTCP
TCP UDP
Network
IP
Network Interface Physical / Data Link
SDP: Session Description Protocol

SIP: Session Initiation protocol
RTP: Real Time Transport Protocol
RTCP: Real Time Control Protocol
72
Características
RFC 3550 proporciona un protocolo de extremo a extremo
adecuado para aplicaciones que transmiten datos en tiempo
real, tales como audio o vídeo a través de servicios de red.
RTP (RTCP) incluye servicios de la identificación del tipo de

carga útil (payload), la secuencia de numeración, sellado de
tiempo y el control de entrega.
RTP es independiente de los protocolos de transporte

responsables de la red subyacente, que se utiliza típicamente
UDP / IP
73
Características (1)
RTP depende (implícitamente) en varios servicios del protocolo
de transporte subyacente, como la multiplexación /
demultiplexación, indicación de longitud.
RTP permite la comunicación multicast, la funcionalidad

básica debe ser proporcionada por la red subyacente.
RTCP (RFC 3550) apoya la calidad de servicio de vigilancia y

transmite información sobre los participantes de la sesión.
74
Características (2)
RTP:
No proporciona ningún mecanismo para garantizar la

entrega oportuna de los paquetes de datos.
No contiene mecanismos para garantizar la calidad de
servicio (QoS).
No garantiza que la secuencia de paquetes recibidos es
igual a la secuencia de los paquetes transmitidos por el
emisor, sin embargo, el número de secuencia se puede
utilizar para reconstruir la secuencia de paquetes del
remitente.
No contiene funciones para corregir errores de secuencia
(compensación de la pérdida de paquetes).
75
Escenario Básico para RTP/RTCP
76
Conceptos RTP: Mezcla & Traductor
77
Predefiniciones RTP
Audio y Video Conferencia:
Los medios de comunicación de audio y vídeo que se utilizan

en una conferencia, se transmiten como sesiones separadas
de RTP.
No hay acoplamiento directo a nivel RTP entre las sesiones de

audio y vídeo, pero si un usuario participante en ambas
sesiones debe utilizar el mismo nombre canónico para ambos
(asociación de sesiones).
La sincronización puede lograrse haciendo uso de las marcas

de tiempo (Timestamps).
78
Predefiniciones RTP (1)
Asignación de puertos:
Las reglas pueden ser sustituidas por las definiciones

específicas del protocolo fuera del RFC 3550.
Para UDP y protocolos similares, RTP DEBE utilizar un

número de puerto de destino par y el flujo RTCP
correspondiente deben utilizar el siguiente número más alto
del puerto de destino (impar).
Si no se proporciona un número impar entonces la aplicación

debe sustituir a ese número con la siguiente inferior (incluso)
el número que se utiliza como base del par de puertos
79
Predefiniciones RTP (2)
Formato PDU: Byte de Orden, Alineación y formato de hora
Formato Big-endian (ilustración y transmisión orden, conforme a

RFC 791)
Todos los datos de cabecera se alinean a su longitud natural, por

ejemplo, 16 bits campos que están alineados incluso en las
compensaciones, los campos de 32 bits están alineados en
desplazamientos divisibles por cuatro, etc.
Los octetos designados como relleno tienen el valor cero.
Tiempo Wallclock (fecha y hora absoluta) se representa con el

formato de fecha y hora del Network Time Protocol (NTP), que está en
segundos relativo a 0h UTC del 01 de enero 1900.
80
Definiciones
Paquete RTP: RTP cabecera + lista de fuentes que
contribuyen * + carga útil
(Bloqueo / desbloqueo del UIT-T X.200 permitido).
Paquete RTCP: parte de la cabecera fija RTP (similar) + tipo

de paquete estructurado específico elementos de enviar
múltiples paquetes como paquetes compuesto.
Dirección de Transporte: dirección de red + puerta de la

capa de transporte.
Tipo de medio RTP: colección de tipos de carga transportada

en una única sesión RTP (definido por un perfil).
* posiblemente vacía.
81
Definiciones (cont.)
Sesión RTP: asociación entre un conjunto de participantes
que se comunican con RTP.
Sesión Multimedia: conjunto de sesiones RTP simultáneas

en un grupo común de participantes.
Fuente de sincronización: fuente de un flujo de paquetes

RTP identificados por un identificador de 32 bits (identificador
es elegido al azar, debe ser exclusivo de un determinado
período de sesiones).
Fuente contribuyente: fuente que contribuye a un flujo

combinado producido por una mezcla de RTP.
82
Formato Paquete RTP
83
Indicación de las Capacidades del
Receptor Utilizando SDP
Ejemplo de
paquete RTP
después de
marcar "911"
84
Campos de la Cabecera RTP (1)
Campos Funciones
V: Version La versión actual es 2 (RFC 3550)
P: Padding El paquete contiene uno o más octetos de relleno
adicionales al final (el último octeto de relleno
contiene el número de octetos de relleno).
X: Extension La cabecera fijas deben ser seguidos por exactamente
una extensión de la cabecera.
CC: CSRC Contar el número de fuentes que contribuyen
fusionadas por un mezclador (15 entradas máx.)
M: Marker Significado esta definido por un perfil
Payload (Type) Formato de la carga útil del dato (payload)
Sequence Number Número de secuencia del paquete:
El valor inicial del número de secuencia debe ser al
azar (texto claro-ataques); incremento es, 1 '
85
Campos de la Cabecera RTP (2)
Campos Funciones
Timestamp Instante de muestreo del primer octeto de la carga útil
(payload); la frecuencia de reloj está dada por un perfil
o el formato de la carga útil; incrementado en uno en
cada valor de muestreo (sin reloj del sistema); valor
inicial de la marca de tiempo DEBE ser al azar;
paquetes RTP consecutivos pueden tener
- Marcas de tiempo iguales (mismos instantes de
muestreo)
- Marcas de tiempo (timestamp) que no son monótonas
(por ejemplo, aleatorización);
SSRC identifier Identificación de la fuente de sincronización; número
aleatorio, la probabilidad de múltiples fuentes de la
elección de la mismo identificador (colisión)
Contributing Src Identificadores de SSRC de las fuentes que contribuyen
a la carga útil adjunta (máx. 15 entradas)
86
RTP Captura Wireshark (1)
SIP Server
UAC 172.22.16.35
192.168.1.161
6000 RTP
RTP
RTP
87
RTP Captura Wireshark (2)
SIP Server
UAC 172.22.16.35
192.168.1.161
6000 RTP
RTP 40648
RTP
88
Protocolo RTP/RTCP
RFC-3550
89
Real Time Control Protocol (RTCP)
Dentro del estándar RFC 3550 se define un protocolo adicional
para el envío de datos de control entre el emisor y receptor de
una secuencia RTP y datos de mediciones realizadas durante la
transmisión.
Se conoce como RTCP RTP Control Protocol. los paquetes RTCP
se envían periódicamente dentro de la secuencia de paquetes
RTP.
Los paquetes RTCP son enviados aproximadamente cada cinco
segundos, y contienen datos que ayudan a verificar las
condiciones de transmisión en el extremo remoto.
Es un protocolo de comunicación que proporciona información de
control que está asociado con un flujo de datos para
una aplicación multimedia (flujo RTP).
Trabaja junto con RTP en el transporte y empaquetado de datos
multimedia, pero no transporta ningún dato por sí mismo.
90
Real Time Control Protocol (RTCP)
Se usa habitualmente para transmitir paquetes de control a
los participantes de una sesión multimedia de streaming.
La función principal de RTCP es informar de la calidad de
servicio proporcionada por RTP.
Este protocolo recoge estadísticas de la conexión y también
información como por ejemplo bytes enviados, paquetes
enviados, paquetes perdidos o Jitter entre otros.
Resumen.
RTCP se usa para informar de la QoS (Quality of Service).

RTCP por sí mismo no ofrece ninguna clase de cifrado de
flujo o de autenticación. Para tales propósitos se puede
usar SRTCP.
91
Cabecera RTCP
Versión: 2 bits. Indica la versión RTP, que es la misma en los
paquetes RTCP que en los RTP.
Padding: 1 bit. Si está activado quiere decir que el paquete contiene

algunos bits de padding al final que no forman parte de la
información de control. El último byte del padding indica cuántos
bytes de padding se tiene que ignorar.
Count: 5 bits. Indica el número de bloques de informes de receptor

contenidos en este paquete.
Type: 8 bits. Indica el tipo de paquete RTCP.
Length: 16 bits. Indica la longitud del paquete RTCP.
92
RTCP Capturado con Wireshark
93
Protocolo SDP
RFC-2327
94
Session Description Protocol (SDP)
IETF RFC 2327
“SDP está destinado a describir sesiones multimedia a los efectos

de anuncio de la sesión, la invitación de sesiones, y otras formas
de iniciación de sesión multimedia.”
Incluye SDP:
El tipo de media (video, audio (voz/modem), imagen, etc.)

El protocolo de transporte (RTP/UDP/IP, H.320, etc.)
El formato de la media (H.261 video, MPEG video, etc.)
Información que reciben los medios (direcciones, puertos,
formatos y así sucesivamente)
95
Elementos de Descripción SDP (1)
SDP tiene dos propósitos principales:
Medio para comunicar la existencia de una sesión.
Medio para transportar la información suficiente para permitir

la unión y participar en la sesión.
96
Información aportada por SDP:
Nombre y propósito Sesión.

Tiempo (s) de la sesión activa.
Los medios de compresión de las sesiones.
La información a recibir de esos medios (direcciones, puertos,
formatos y demás).
Información sobre el ancho de banda que se utilizará en la
conferencia.
Información de contacto de la persona responsable de la
sesión por parte del usuario.
97
Formato:<tipo>=<valor>
Reglas
<tipo>: exactamente un carácter, caso significativo
<valor>: cadena de texto estructurado, de casos y significativo

a menos que se defina lo contrario
<valor>: es un número de valores delimitado por un único

carácter de espacio
Los espacios en blanco no está permitido en cada lado del

signo "=“
98
Anuncio consiste en:
Una sección de nivel de sesión
Uno o más apartados de nivel de medios (códec)
Los valores de nivel de sesión pueden ser anulados por los

valores de nivel de los medios de comunicación (códec).
Ejemplo: i= Conferencia sobre Redes de Comunicación
99
Descripción de Sesion
v= (protocol version)
o= (owner/creator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information)
b=* (bandwidth information)
One or more time descriptions (see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
100
Descripción de Tiempo
t= (time the session is active)
r=* (zero or more repeat times)
Descripción de Media
m= (media name and transport address)
i=* (media title)
c=* (connection information)
b=* (bandwidth information)
k=* (encryption key)
a=* (zero or more media attribute lines)
(*): Ítem opcional
101
Elementos SDP (1)
Attribute: Protocol Version
Syntax: v=<version number>
Description: Version of SDP
Ejemplo: v=0
Attribute: Origin
Syntax: o=<username> <session id> <version> <network type>
<address type>
<address>
Description: da el creador de la sesión más un identificador de sesión
y un numero de la versión de sesión
Ejemplo : o=sboehmer 2890874556 2010664123 IN IP4

194.95.66.4
102
Elementos SDP (2)
Attribute: Session Name
Syntax: s=<session name>
Description: Único nombre de la sesión
Ejemplo: s=Explicación actual de la comunicación de red
Attribute: Session Information

Syntax: i=<session description>
Description: Contiene información acerca de la sesión
Ejemplo: i=Esta información es sobre la descripción de la

sesión multimedia usando SDP
103
Elementos SDP (3)
Attribute: URI
Syntax: u=<URI>
Description: Universal Resource Identifier deben apuntar a obtener
información adicional acerca de la sesión.
Ejemplo: u=http://www.comnets.brsu.de/Lehre/SS2010CN2.html
Attribute: Dirección Email Address y Numero telefónico

Syntax: e=<email address> resp. p=<phone number>
Description: Información de contacto de la persona responsable de la
conferencia
Ejemplo: e=stefan.boehmer@brsu.de
p=+49-2241-865-227
104
Elementos SDP (4)
Attribute: Datos de la conexión
Syntax: c=<network type> <address type> <connection address>
Description: Datos de conexión en el nivel de sesión o en cada
descripción de medios
Ejemplo: c=IN IP4 224.2.1.1/127
Attribute: Bandwidth
Syntax: b=<modifier>:<bandwidth-value>
Description: Ancho de banda que se propone utilizar en la sesión o
de los medios de comunicación
Ejemplo: b=AS:128
105
Elementos SDP (5)
Attribute: Time, Repeat Time and Time Zone
Syntax: t=<start time> <stop time>
r=<repeat interval> <active duration> <list of offsets from start-time>
z=<adjustment time> <offset> …
Description: Varias especificaciones de tiempo de conferencia
Ejemplo: t=3034423619 3042462419
r=7d 1h 0 25h
z=2882844526 -1h 2898848070 0
Attribute: Encryption key

Syntax: k=<method>:<encryption key>
Description: Llevar la información de encriptacion para un flujo de
media.
Ejemplo:
k=base64:sRipl6EpM7aPTSvk7zLqULf6BqEKJ2dcQJDYnDD
106
Elementos SDP (6)
Attribute: Attribute
Syntax: a=<attribute>:<value>
Description: Lleva informacion adicional (extensión SDP)
Example: a=sendrecv
Attribute: Media Announcement

Syntax: m=<media> <port> <transport> <fmt list>
Description: Describe propiedades de la media
Example: m=video 49232 RTP/AVP 0
107
Ejemplo: Elementos de Descripción SDP
(1)
Session Descripcion Protocol
Session Descripcion Protocol version (v):0
Owner/Creator, Session Id (o): AudiocodesGW 32878409
32878301 IN IP4 10.194.172.2
Session Name (s): Phone-Call
Connection Information (c): IN IP4 10.194.172.2
Time Description. Active time (t): 0 0
Session-Level information
108
Ejemplo: Elementos de Descripción SDP
(2)
Media Description, name and address (m): audio 6000 RTP/AVP 8 18 96 100
Media Attribute (a): rtpmap: 8 PCMA/8000
Media Attribute (a): fmtp: 8 vad=no
Media Attribute (a): rtpmap: 18 G729/8000
Media Attribute (a): fmtp: 18 annexb=no
Media Attribute (a): gpmd: 96 vbd=yes
Media Attribute (a): rtpmap: 100 telephone-event/8000
Media Attribute (a): fmtp: 100 0-15
Media Attribute (a): ptime:20
Media Attribute (a): sendrecv
Media Attribute (a): rtcp:6001 IN IP4 10.194.172.2
Media-Level information
109
Ejemplo – SDP (Session Level Information)
110
Ejemplo – SDP (Session Media Information)
AVP = Audio Video profile

over UDP [RFC 3551]
111
SDP Capturado con Wireshark
Session Level Information
Session Media Description

112
Configuración de Gateway SIP
113
ip ifdelete intf IPVoz
eth ifdelete intf ethVoz
eth ifadd intf ethVoz
eth ifconfig intf ethVoz dest vdsl2 vlan voz
eth ifattach intf ethVoz
ip ifadd intf IPVoz dest ethVoz
ip ifattach intf IPVoz
ip ipadd intf IPVoz addr=10.178.208.136/25
ip rtadd dst=190.98.230.5/32 gateway=10.178.208.129
voice profile add SIP_URI=u228836925 username=u228836925
password=p228836925 displayname=223499060 voiceport=FXS1
enable=enabled
service system modify name=VOIP_SIP state=enabled
saveall
114
Habilitar servicios de voz SIP
Configuración de servicios SIP
Transporte
Lazo de interface
Configuración de un User Agent SIP (UA).
Temporización
Autenticación
Servidores SIP
Configuración de parámetros dial-peer SIP.
Protocolo sesión
Objetivo de la sesión
DTMF
115
Proceso de Registro SIP
116
Dirección de Registro
Servidor Servidor Base de datos
Registro Redirect de
Localización
Proxy SIP
(UAS)
Register
Aquí yo
soy
SIP UACs
SIP UACs
Gateway
SIP
117
Resolución de Dirección
Servidor Servidor Base de datos

Registro Redirect de
Localización
¿Donde esta el nombre

o numero telefónico?
Proxy SIP
118
Proceso de Registro
Es un Mecanismo.
Donde el usuario (UAC) se presenta a un servidor de registro

(UAS) con su userSIP (usuario@dominio) y dirección física
(dirección IP).
Esta asociación tiene un período de vigencia (default 3600 seg.)
Ejemplo:
Cuando un usuario inicializa su terminal (por ejemplo
conectando su teléfono o abriendo su software de telefonía SIP,
el agente de usuario SIP que reside en dicho terminal envía una
petición con el método REGISTER a un Servidor de Registro,
informando a qué dirección física debe asociarse la dirección
lógica del usuario.
119
Autenticación SIP (1)
Comprobación de identidad (seguridad).
Es una función de plataforma VoIP (Siemens, Broadsoft,

Cisco, Huawei, ZTE, etc.).
Utiliza un método de Petición-Respuesta.
Se basa en la autenticación HTTP (Digest Authentication).
Evita el envío de la contraseña de los usuarios en texto plano.
Se usa una función hash MD5.
120
Autenticación SIP (2)
Funcionamiento:
Cuando un cliente intenta establecer un contacto con el
servidor, éste responde con un mensaje que incluye un
valor aleatorio (nonce) junto al dominio contra el que se va a
autenticar (realm).
Entonces, el cliente debe enviar una respuesta cifrada al

servidor en un mensaje de tipo response, indicando el
nonce, el realm junto con el nombre de usuario, el uri y la
contraseña.
Una vez recibidos estos datos, el servidor compara el valor

de la respuesta del cliente con el resultado de cifrar él por
su cuenta los mismos datos, con la contraseña que tiene del
cliente.
121
Ejemplo de Autenticación SIP
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
realm="movistar.cl",nonce="BroadWorksXhqs0lx9nT9nzu0iBW",alg
orithm=MD5,qop="auth“
REGISTER sip:172.23.6.3;transport=UDP SIP/2.0
Authorization: Digest
username="225399043",realm="movistar.cl",nonce="BroadWorksX
hqs0lx9nT9nzu0iBW",uri="sip:172.23.6.3;transport=UDP",response
="244f0da36dca206ac01b54846995dc0d",algorithm=MD5,cnonce="
3a0b66e",qop=auth,nc=00000001
122
Flujo Autenticación SIP
CLIENTE SERVIDOR
PETICIÓN
Genera el
valor nonce
RESPUESTA
nonce, dominio
Respuesta del cliente =
F(nonce, usuario, contraseña, dominio)
PETICIÓN
nonce, dominio
usuario, respuesta
Autenticación: calcula
F(nonce, usuario, contraseña, dominio)
Y compárala con la respuesta
123
SIP Registration
Yo soy el
numero
223499020 OK envíame tus
credenciales para
autenticarte
Perfecto,
hay van mis
credenciales OK, estas
registrado y
En este instante el autenticado
led voice/phone se
encienden en el
modem y la
puerta FXS queda
con tono de discar
124
SIP Registration (1)
SIP Server
UAC
Cliente UAC
solicita registro REGISTER
REGISTER sip:172.23.6.3:5060;transport=UDP SIP/2.0

From: <sip:582222041@claro.cl:5060>;tag=1465e88-ab2d088-13c4-50029-1653-d39827-1653
To: <sip:582222041@claro.cl:5060>
Call-ID: 14b25d0-ab2d088-13c4-50029-1653-67df03f9-1653
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 10.178.208.136:5060;branch=z9hG4bK-1653-573596-880e9ed
Max-Forwards: 70
Supported: replaces,100rel
User-Agent: Thomson TG789vn Build 8.4.3.U
Expires: 300
Contact: <sip:582222041@10.178.208.136:5060>
X-Serialnumber: CP1151QTACY
Accept: application/dtmf-relay, x-application/dtmf-relay, application/sdp
Content-Length: 0
125
SIP Server
UAC
El servidor de REGISTER
registro envía al 401 Unauthorized

cliente la petición
SIP/2.0 401 Unauthorized
To: <sip:582222041@claro.cl:5060>;tag=465014615-1350534427299
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 10.178.208.136:5060;branch=z9hG4bK-1653-573596-880e9ed
WWW-Authenticate: Digest realm="BroadWorks",nonce="BroadWorksXh8fdbterTmknsx0BW“
,algorithm=MD5,qop="auth"
Content-Length: 0
126
SIP Registration (3) SIP Server
UAC
El cliente UAC envía

la respuesta a la REGISTER
petición generada 401 Unauthorized
por el servidor
REGISTER
REGISTER sip:172.23.6.3:5060;transport=UDP SIP/2.0

To: <sip:582222041@claro.cl:5060>
CSeq: 2 REGISTER
Via: SIP/2.0/UDP 10.178.208.136:5060;branch=z9hG4bK-1653-5735b8-2f6328e3
Max-Forwards: 70
User-Agent: Thomson TG789vn Build 8.4.3.U
Expires: 300
Authorization: Digest username="58222041",realm="BroadWorks",nonce="BroadWorksXh
8fdbterTmknsx0BW",uri="sip:172.23.6.3:5060;transport=UDP",response="780b24c88eec8187a8fb55bf5c48fc
ac",algorithm=MD5,cnonce="5735b8",qop=auth,nc=00000001
Contact: <sip:582222041@10.178.208.136:5060>
X-Serialnumber: CP1151QTACY
Content-Length: 0
127
SIP Server
UAC
REGISTER
El servidor de
401 Unauthorized
D:\Respaldos\
registro envía al
REGISTER
cliente la petición
Alfonso 2012\Homologación\Ca
aceptada 200 OK
SIP/2.0 200 OK
To: <sip:582222041@claro.cl:5060>;tag=691330922-1350534427337
CSeq: 2 REGISTER
Via: SIP/2.0/UDP 10.178.208.136:5060;branch=z9hG4bK-1653-5735b8-2f6328e3
Contact: <sip:582222041@10.178.208.136:5060>;expires=300;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-
hoteling,x-broadworks-call-center-status
Content-Length: 0
128
¿Que pasa después de este proceso en los terminales VoIP?
El indicador luminoso Phone/Voice/FXS se enciende
¿Que debo percibir en las puertas FXS/PBX IP/IP Phone?
Se debe percibir tono de discar (entrada/salida)
129
Consideraciones del Proceso Registro
Perdida de Conectividad
404 Not Found
Definir acciones a seguir por los dispositivo SIP.

Reintentos.
Cantidad.
Tiempos.
130
Perdida de Conectividad
UAC Proxy
Server
REGISTER (Via: Expires: 300)
REGISTER (Via: Expires: 300) 2seg
5 veces
35 seg.

5 veces
131
404 Not Found
UAC Server
Proxy
404 Not Found
404 Not Found
30 seg.
404 Not Found
404 Not Found
132
Errores de REGISTRO
133
401 Unauthorized (1)
134
SIP Server
UAC
D:\Respaldos\
REGISTER
401 Unauthorized
135
SIP Server
UAC
D:\Respaldos\
REGISTER
401 Unauthorized
REGISTER
401 Unauthorized
136
404 Not Found (1)
SIP Server
UAC
D:\Respaldos\
REGISTER
404 Not found
REGISTER
404 Not found
137
404 Not Found (2)
SIP Server
UAC
D:\Respaldos\
REGISTER
404 Not found
REGISTER
404 Not found
138
Registration Error
SIP Server
UAC
D:\Respaldos\
REGISTER
REGISTER
REGISTER
REGISTER
139
Flujo de Llamada SIP
140
Flujo General Llamada SIP
UAC DSLAM
Analog
Red
Phone V
IP
Register
401 Unauthorized
Register
Off-hook 200 OK
Dial Tone
Dialing
INVITE
100 Trying
180 Ringing
Ringback Tone
200 OK (SDP)
ACK
Voz Analógica Voice (Flujo RTP)
On-hook BYE
200 OK
141
INVITE
SIP
Server
UAC
FXS V
INVITE
142
INVITE
INVITE sip:96912384@claro.cl:5060;transport=UDP SIP/2.0
From: "23499026"<sip:23499026@claro.cl:5060>;tag=150c600-ab2d089-13c4-50029-
11b29-1832eb4f-11b29
To: "96912384"<sip:96912384@claro.cl:5060>
Call-ID: 1503b60-ab2d089-13c4-50029-11b29-2c1bf4a1-11b29
CSeq: 1 INVITE
Via: SIP/2.0/UDP 10.178.208.137:5060;branch=z9hG4bK-11b29-4521aad-5d81f5
Max-Forwards: 70
User-Agent: Technicolor TG789vn v3 Build 10.2.1.4
Contact: <sip:23499026@10.178.208.137:5060>
X-Serialnumber: CP1201RA9N6
Allow: INVITE, ACK, BYE, REFER, NOTIFY, CANCEL, OPTIONS, INFO, UPDATE,
PRACK
Content-Type: application/sdp
Content-Length: 271
143
INVITE (cont.)
INVITE sip:96912384@claro.cl:5060;transport=UDP SIP/2.0
v=0
o=789vn_v3 946761472 946761472 IN IP4 10.178.208.137
s=-
c=IN IP4 10.178.208.137
t=0 0
m=audio 1102 RTP/AVP 8 18 97
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:8 vad=no
a=fmtp:18 annexb=no
a=ptime:20
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15
144
100 Trying
SIP
Server
UAC
FXS V
INVITE
100 Trying
SIP/2.0 100 Trying

11b29-1832eb4f-11b29
To: "96912384"<sip:96912384@claro.cl:5060>
CSeq: 1 INVITE
145
180 Ringing
SIP
Server
UAC
FXS V
INVITE
100 Trying
180 Ringing
146
180 Ringing
SIP/2.0 180 Ringing
From: "23499026"<sip:23499026@claro.cl:5060>;tag=150c600-ab2d089-13c4-50029-11b29-1832eb4f-11b29
To: "96912384"<sip:96912384@claro.cl:5060>;tag=590598661-1349957798656
CSeq: 1 INVITE
Supported:
Contact: <sip:96912384@172.22.16.35:5060;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Content-Length: 273
v=0
o=BroadWorks 16592133 1 IN IP4 172.22.16.35
s=-
c=IN IP4 172.22.16.35
t=0 0
a=fmtp:8 vad=no
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:97 0-15
a=sendrecv
a=ptime:20
147
200 OK with Session Description Protocol
SIP
Server
UAC
FXS V
INVITE
100 Trying
180 Ringing
200 OK, with SDP
148
200 OK with Session Description Protocol
SIP/2.0 200 OK
From: "23499026"<sip:23499026@claro.cl:5060>;tag=150c600-ab2d089-13c4-50029-11b29-1832eb4f-11b29
CSeq: 1 INVITE
Supported:
Accept: application/media_control+xml,application/sdp
Content-Length: 273
v=0
s=-
c=IN IP4 172.22.16.35
t=0 0
a=fmtp:8 vad=no
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:97 0-15
a=sendrecv
a=ptime:20
149
ACK
SIP
Server
UAC
FXS V
INVITE
100 Trying
180 Ringing
200 OK, with SDP

ACK
150
ACK
ACK sip:96912384@172.22.16.35:5060;transport=udp SIP/2.0
11b29-1832eb4f-11b29
CSeq: 1 ACK
Via: SIP/2.0/UDP 10.178.208.137:5060;branch=z9hG4bK-11b2c-4522610-1fad61da
Max-Forwards: 70
Contact: <sip:23499026@10.178.208.137:5060>
Content-Length: 0
151
Voice Flow RTP
SIP
Server
UAC
FXS V
INVITE
100 Trying
180 Ringing
200 OK, with SDP

ACK
Voice RTP
152
BYE
SIP
Server
UAC
FXS V
INVITE
100 Trying
180 Ringing
200 OK, with SDP

ACK
Voice RTP
BYE
153
BYE
BYE sip:23499026@10.178.208.137:5060 SIP/2.0
From: "96912384"<sip:96912384@claro.cl:5060>;tag=590598661-1349957798656
To: "23499026"<sip:23499026@claro.cl:5060>;tag=150c600-ab2d089-13c4-50
029-11b29-1832eb4f-11b29
CSeq: 669033385 BYE
Via: SIP/2.0/UDP
172.22.16.35:5060;branch=z9hG4bKkpug9n2080sgim8dq0k1sd71o7qk2.1
Max-Forwards: 9
Content-Length: 0
154
200 OK
SIP
Server
UAC
FXS V
INVITE
100 Trying
180 Ringing
200 OK, with SDP

ACK
Voice RTP
BYE
200 OK
155
200 OK
SIP/2.0 200 OK
From: "96912384"<sip:96912384@claro.cl:5060>;tag=590598661-1349957798656
To: "23499026"<sip:23499026@claro.cl:5060>;tag=150c600-ab2d089-13c4-50029-
11b29-1832eb4f-11b29
CSeq: 669033385 BYE
Via: SIP/2.0/UDP
172.22.16.35:5060;branch=z9hG4bKkpug9n2080sgim8dq0k1sd71o7qk2.1
Content-Length: 0
156
Configuración Llamado Usando un Servidor Proxy
Servidor Proxy
Gateway SIP Gateway SIP
Red IP
Parte Parte Llamado

Llamador INVITE (SDP) INVITE (SDP)
Señalización SIP 100 Trying

y SDP 100 Trying
(UDP o TCP) 180 Ringing
180 Ringing
200 OK (SDP)
200 OK (SDP)
ACK
ACK
Portadora o Flujo RTP

medio
BYE BYE
(UDP)
200 OK 200 OK
157
Procedimiento de Establecimiento de
Llamada con un Servidor Proxy
1. El UAC originario envía un INVITE al Servidor Proxy.
2. El Servidor Proxy, si es necesario, consulta al servidor de
localización para determinar la ruta del destinatario y su dirección
IP.
3. El Servidor Proxy envía el INVITE a los UAS del destinatario.
4. Si el UAS del destinatario determina que los parámetros de
llamada son aceptables, responde positivamente al Servidor Proxy.
5. El Servidor Proxy responde al UAC originario.
6. El UAC que origina emite un ACK.
7. El Servidor Proxy reenvía el ACK a la UAS destinatario.
Los UAC y UAS ahora tienen toda la información que se requiere

para establecer sesiones RTP entre ellos.
158
Configuración Llamado Usando un Servidor de Redirección
Servidor
Gateway SIP Redirect Gateway SIP Parte Llamado
Red IP
Parte INVITE (SDP)

Llamador
Señalización SIP Moved

y SDP INVITE (SDP)
(UDP o TCP)
100 Trying
180 Ringing
200 OK (SDP)
ACK
Portadora o Flujo RTP

medio
(UDP) BYE
200 OK
159
Procedimiento de Establecimiento de
Llamada con un Server Redirect
1. El UAC originario envía un INVITE al servidor de redirección.
2. El servidor de redirección, si es necesario, consulta el servidor de
localización para determinar la ruta de acceso a al destinatario y
su dirección IP.
3. El servidor devuelve una respuesta de redireccionamiento "movido"
para el UAC originario con la dirección IP
obtenida desde el servidor de ubicación.
4. El UAC originario reconoce la redirección.
5. El UAC originario envía un INVITAN al UAS remoto..
6. Si la UAS del destinatario determina que los parámetros de
llamada son aceptables, responde
positivamente a la UAC.
7. El UAC se origina emite un ACK.
El UAC y UAS ahora tienen toda la información que se requiere

para establecer sesiones RTP entre ellos.
160
Extensiones del Protocolo SIP
161
CANCEL
El método “CANCEL” es utilizado para pedir al abandono de la llamada en curso
pero no tiene ningún efecto sobre una llamada ya aceptada. De hecho, solo el
método “BYE” puede terminar una llamada establecida.
SIP
Server
UAC
FXS V
INVITE
100 Trying
180 Ringing
CANCEL
162
CANCEL
163
OPTIONS
El método “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.
PBX IP SBC
FXS
OPTIONS
200 OK
164
INFO
SIP
El método INFO (RFC Server
2976) permite transferir UAC
informaciones de
señalización durante la FXS V
llamada.
Entre los ejemplos de INVITE
información se 100 Trying
encuentran los dígitos 180 Ringing
DTMF, las informaciones
200 OK, with SDP
relativas a la tasación de
una llamada, las ACK
imágenes etc... Evento Voice RTP
de Flash INFO
200 OK
165
INFO
166
REFER
El método REFER (RFC 3515) re envía el receptor hacia un
recurso identificado en el método. REFER permite emular
distintos servicios o aplicaciones incluyendo la transferencia de
llamada.
Examples
Refer-To: sip:alice@atlanta.example.com
Refer-To: sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk. biloxi.example.net&Call-
ID%3D55432%40alicepc.atlanta.example.com
Refer-To: sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B to-
tag%3D12345%3Bfrom-tag%3D5FFE-3994
Refer-To: sip:carol@cleveland.example.org;method=SUBSCRIBE
Refer-To: http://www.ietf.org Long headers field values are line-wrapped here for clarity only.
167
SUBSCRIBER
Una entidad SIP se puede suscribir a un evento con el fin de ser
notificada de su ocurrencia.
El requerimiento SUBSCRIBE permite la suscripción mientras el
requerimiento NOTIFY es utilizado con el fin de notificar (RFC
3265).
Server
UAC
FXS V
SUBSCRIBER
200 OK
168
NOTIFY
La respuesta a un mensaje SIP
Subscribe normalmente es Server
un mensaje NOTIFY (RFC UAC
3265).
Este tipo de mensaje, FXS V
notifica el estado de
SUBSCRIBER
presencia del usuario, y
200 OK
transporta el estado en el
que se encuentra el NOTIFY
usuario. 200 OK
Con la respuesta Notify se
confecciona una lista de
usuarios “notify list”.
169
PRACK
El método PRACK (RFC 3262) ha sido definido con el fin de satisfacer
la recepción de respuestas temporarias de tipo 1XX.
UAC
SIP
Server
FXS V
INVITE
100 Trying
180 Ringing
PRACK
200 OK, with SDP
Voice RTP
BYE
200 OK
170
UPDATE
o El método UPDATE (RFC 3311) permite a un terminal SIP actualizar
los parámetros de una sesión multimedia (ejemplo : flujo media y sus
codecs).
o El método UPDATE puede ser enviado antes de que la sesión sea
establecida.
o UPDATE es entonces particularmente útil cuando se trata de poner
al día los parámetros de sesión antes de su establecimiento, por
ejemplo una puesta en espera del destinatario.
SIP
Server
UAC
FXS V
UPDATE
200 OK
171
MESSAGE
• El método MESSAGE (RFC 3428) ha sido propuesto como extensión
al protocolo SIP con el fin de permitir la transferencia de mensajes
instantáneos.
• La mensajería instantánea o “Instant Messaging” o “IM” consiste en
el intercambio de mensajes entre usuarios en seudo tiempo real.
• Este nuevo método 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 basándose sobre la codificación MIME.
172
SIP
Atributos de Negociación
173
Voice Activity Detection
Códec G.711A
174
Voice Activity Detection (VAD)
Es una técnica utilizada en el procesamiento de voz en el que
se detecta la presencia o ausencia del habla humana.
Los principales usos de VAD están en la codificación de voz y

en el reconocimiento del habla.
Se puede facilitar el procesamiento del habla, y también

puede ser usado para desactivar algunos procesos durante la
sección de no voz de una sesión de audio: puede evitar
innecesarias codificación / transmisión de los paquetes de
silencio en aplicaciones de voz sobre protocolo de Internet, el
ahorro en el cálculo del ancho de banda de la red.
175
Ejemplo – Negociación de VAD
Owner/Creator, Session Id (o): AudiocodesGW 32878409 32878301 IN IP4 10.194.172.2
Media Attribute (a): rtpmap: 18 G729/8000 Descriptor de medios
Media Attribute (a): fmtp: 18 annexb=no de uso general
Voice
Activty
Media Attribute (a): rtpmap: 100 telephone-event/8000 Detection
Media Attribute (a): pmft:T38
176
Negociación de VAD=no
SIP
Server
UAC
FXS V
INVITE
100 Trying
Media Attrbute (a): rtpmap: PCMA/8000
Media Attribute (a): fmtp: 8 vad=no 180 Ringing
200 OK, with SDP

ACK
Media Attribute (a): fmtp: 8 vad=no Voice RTP
BYE
200 OK
177
Ejemplo – Negociación de VAD
Media Attribute (a): fmtp: 8 vad=yes
Media Attribute (a): rtpmap: 18 G729/8000 Descriptor de medios
Voice
Activty
Media Attribute (a): rtpmap: 100 telephone-event/8000 Detection
178
Negociación de VAD=yes
SIP
Server
UAC
FXS V
INVITE
100 Trying
Media Attribute (a): fmtp: 8 vad=yes 180 Ringing
200 OK, with SDP

ACK
Media Attribute (a): fmtp: 8 vad=yes Voice RTP
RTP (CN)
RTP (CN)
179
Ruido de Fondo - (Comfort Noise)
Comfort Noise es un ruido blanco.
Inyectado en los intervalos de silencio de una comunicación.
Voice activity detection (VAD)
Transmisor Gateway Gateway Receptor

Voz Voz
Network
RTP (CN) RTP (CN)
VAD VAD
Inicia
conversación
Ruido de fondo
180
Recomendación
UIT-T G.729 Anexo B
181
Anexo B (Compresión de Silencios)
Algoritmo de compresión de silencios para la Recomendación
G.729.
El Anexo B define un detector de actividad vocal y un

generador de ruido para la comodidad de la audición.
Se presenta una descripción de los algoritmos de:
Detección de actividad vocal (VAD, voice activity detection),

Transmisión discontinua (DTX, discontinuous transmission).
Generador de ruido de comodidad de la audición (CNG,
comfort noise generator).
182
Anexo B (Compresión de Silencios)
Estos algoritmos se utilizan para reducir la velocidad de
transmisión durante los periodos de silencio en la
conversación.
Opciones de anexo B en protocolo SDP:

Media Attribute (a): fmtp: 18 annexb=yes
183
Sistema de Codificación de Conversación
con Detección de Actividad Vocal
184
Ejemplo – Negociación de Anexo B
Descriptor de medios
Media Attribute (a): gpmd: 96 vbd=yes Anxo=b, define los
algoritmos, para la
negociación de los
Media Attribute (a): fmtp: 100 0-15 silencios en la
Media Attribute (a): ptime:20 comunicación
185
Estándar ITU-T V.152
Recomendación ITU-T V.152
Requerimientos mínimos de operación para el modo VBD.
Para los efectos de la interoperabilidad, una aplicación

compatible V.152 deberá soportar al menos dos códec VBD
(G.711 ley A y G.711 ley µ) .
Al negociar el códec VBD, la aplicación inicia V.152 debe
incluir en la oferta o bien PCMA o PCMU (o ambos) en la lista
de códecs VBD, aunque otros códecs VBD pueden
especificarse adicionalmente.
La implementación V.152 debe responder a la oferta
indicando el apoyo de al menos un códec VBD, que no
necesita ser basada en PCM.
Redundancia según IETF RFC2198 y corrección de errores
según IETF RFC2733 se admiten opciones.
187
Recomendación ITU-T V.152 (cont.)
Procedimiento para el transporte de datos sobre la banda de
voz en redes IP.
Transporte de datos modulados en la banda de voz (VBD).
Voice-band Data (VBD).
Datos de modem, fax y terminales de textos.
VBD se refiere a la conmutación del códec en la banda de voz

para el transporte de datos con payloads en flujo RTP.
188
Recomendación ITU-T V.152 (cont.)
Implementación de atributo para negociación usando SDP
gpmd (general-purpose media descriptor)

a=gpmd:<format> <parameter list>
a=gpmd:96 vbd=yes
a=maxmptime:<list of packet times separated by space>

a=ptime:<list of packet times separated by space> (RFC
2327)
a=ptime:20
189
Ejemplos
Example 1 Nota
m=audio 3456 RTP/AVP 18 0 13 96 98 99 m=audio 15400 RTP/AVP 0 18
a=maxmptime:10 10 - - 20 20 a=gpmd:0 vbd=yes
a=fmtp:96 0-15, 34, 35 m=audio 15400 RTP/AVP 0 18
a=rtpmap:98 PCMU/8000
a=gpmd:98 vbd=yes
a=rtpmap:99 G726-32/8000
a=gpmd:99 vbd=yes
Example 2
a=gpmd:0 vbd=yes
a=rtpmap:98 G726-32/8000
a=gpmd:98 vbd=yes
a=ptime:20
190
Ejemplo – Negociación VBD
Descriptor de medios
Media Attribute (a): rtpmap: 18 G729/8000 de uso general
gpmd: general-purpose
media descriptor
Recomendación
V.152
Media Attribute (a): ptime:20 Voice
Band
Media Attribute (a): pmft:T38 Data
191
Negociación de VBD=yes
SIP
Server
UAC
FXS V
POS
192
Negociación de VBD=yes
193
RFC-2833
RFC-2833
Define un método para transporte de audio en la banda de
señalización de tonos a través de una red de paquetes -
principalmente para la reinserción en la PSTN.
El formato del payload RTP se designa como "telephone-event", el

tipo de MIME como "audio / telephone-event".
En este modo (RFC 2833), los dígitos DTMF son transportados al

lado remoto como parte de un flujo RTP (Real-Time Transport
Protocol).
El formato del payload no tiene un número de payload type estático,

sino que utiliza un número de payload type RTP establecido
dinámicamente y fuera de banda.
195
RFC-2833 (cont.)
DTMF SIP sobre Cisco Unified Communications Manager.
DTMF SIP requiere MTP Cisco Unified Communications

Manager
196
RFC-2833 (cont.)
Los tipos de transporte de una señal Dual-Tone Multi Frequency
(DTMF) pueden ser enviados a través de 3 modos:
In-band: La información DTMF es enviada junto con el flujo de

voz. Este método es el menos confiable. Se aconseja utilizar este
método solamente en combinación con códec de alta velocidad
(tales como los codec G711 ley A y ley u).
SIP INFO: La información DTMF es enviada a lo largo del canal de

comunicación del llamado. Para mayor información esta puede ser
encontrada en la RFC-2976.
RFC-2833. payload type dinámico del evento telefónico (96 a 127)

m=audio 51326 RTP/AVP 8 18 100 96
197
Tipos de Transporte DTMF
Eventos DTMF
198
SIP: Evento RTP - DTMF
199
SIP
Transporte de Datos
200
Transporte de Datos Modulados sobre Redes IP
El trafico de Fax y modem, consiste en un dato digital modulado en
tonos de alta frecuencia.
En contraste a la voz, la perdida de paquetes es mucho más critica

para las comunicaciones de fax y modem.
Los algoritmos de compresión VoIP, son diseñados para la voz, no

para frecuencias de datos como fax o modem.
Métodos de transmisión de fax o modem sobre redes IP:

Terminación y transmisión de datos sobre un gateway (fax relay)
Envío de datos en banda en el flujo RTP (stream).
Recepción y conversión de faxes a archivos usando T.37 (store-and-
forward)
201
Técnicas de Transmisión
Fax
Técnicas de Transmisión de Fax
Fax relay
Cisco fax relay
T.37 Fax Store and Forward
Fax Pass-Through
T.38 fax relay
203
Fax Relay
• El flujo de bits digitalizado se convierte en una señal
analógica para ser transmitida a través de circuitos de voz.
• Si el equipo de Cisco trata las llamadas de fax como
llamadas de voz, la forma de onda analógica
sería convertida en PCM G.711 a 64 kbps y posteriormente
se comprime antes de ser transmitida a través de la red
VoIP.
• El tratamiento de las llamadas de fax como

llamadas de voz no es práctico
porque hay muchas conversiones y porque los
esquemas de codificación y compresión son
diseñado para transmitir la voz humana, no para
tonos de fax módem.
204
Cisco Fax Relay
• DSP establece primero la llamada como una llamada de
voz de extremo a extremo.
• DSP reconoce las tonalidades como los procedentes de
una máquina de fax.
• DSP local, asume el papel de un fax-módem, convierte
los datos analógicos de nuevo en un flujo de bits
digitalizados originales.
• DSP actuando como módem de fax, baja la velocidad a
9,6 kbps para ahorrar ancho de banda en la ruta de
acceso IP.
• El flujo de bits se empaqueta entonces en los

paquetes de VoIP y se identifica como un fax.
• DSP a distancia asume un papel similar y
convierte el flujo de bits analógico a la recepción
del fax remoto.
205
Fax T.37 Store and Forward
206
Fax Pass-Through
• Fax Pass-Through se produce cuando los datos
entrantes de fax T.30 no son demodulado o
comprimido para su tránsito a través de la red de
paquetes.
• Los dos aparatos de fax se comunican directamente
entre sí a través de una conexión IP transparente.
• Cuando una puerta detecta un tono de fax, conmuta la
llamada a un códec de gran ancho de banda.
• El tráfico de fax, viaja dentro de la banda VoIP

usando G.711 (64 kbps) sin VAD.
• Es muy sensible a la pérdida de paquetes,
fluctuación de fase, y la latencia en la red IP,
aunque paquete redundancia se puede utilizar para
mitigar los efectos de la pérdida de paquetes.
207
Fax G3 T.30 sobre PSTN
La especificación ITU T-30 describe el procedimiento para el control de
sesión.
La especificación ITU T.4 describe el procedimiento de transferencia de
imagen.
El canal 2 de modem a 300 bps half-duplex, es seleccionado como modem
handshake T.30 y para la transferencia de imágenes T.4 aplican varios
métodos.
Procedimiento del control de sesión (fases)
Fase A: Configuración de llamada.
Fase B: Procedimiento de pre mensaje para identificar y seleccionar el
facsímil.
Fase C: Transferencia de imagen.
Fase D: Procedimiento de pre mensaje incluyendo muti paginas y
procedimiento de señalización de fin.
Fase E: Liberación del llamado.
208
T.38 Fax Relay
• T.38 es una recomendación ITU para el envío de mensajes de fax sobre

redes IP en tiempo real pero encapsulando un estándar fax G3 en un
flujo de datos.
209
T.38 Fax Relay
Fax G3
Inicia el Fax
Gateway Gateway G3
llamado
Red IP
T.30 Llamado de voz T.30

Tono CED
Mensaje DIS
INVITE (T.38 en SDP)
Según la norma,
200 OK (SDP)
el dispositivo
receptor debe
ACK
negociar el t.38
con un mensaje T.38 en paquetes UDP
INVITE
2do. INVITE en la
negociación
210
INVITE T38
Owner/Creator, Session Id (o): Broadworks 5786855 3 IN IP4 172.22.16.35
Session Name (s): -
Media Description, name and address (m): image 54524 udptl t38
Media Attribute (a): T38FaxVersio:0
Media Attribute (a): T38MaxBitRate: 14400
Media Attribute (a): T38FaxRateManagement:transferedTCF
Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy
Media Attribute (a): T38FaxMaxDatagram:1472
211
Flujo Fax T.38
Audio
Datos
Fax
Fax=1100Hz
Modem=1300Hz
212
Flujo Fax T.38
Atributos de
T.38
Desconexión
213
Técnicas de Transmisión
Modem
Consideraciones Modem Relay
El módem relay incluye estas funcionalidades:
Detección de tono de módem y señalización.
Switchover relay.
Payload redundante.
Tamaño del paquete.
Buffer para jitter dinámico y estático.

.
215
Topología Relay
0110011 0110011
Modulación
Demodulador DSP DSP
Red IP
Dato Dato
Analógico Analógico
Transmisión TCP de
0110011 paquetes de datos 0110011
Conexión 1 Conexión 2 Conexión 3
• Este método no usa códec.

• Modula y demodula en 4KHz
216
Modem Relay
Las señales de módem son demoduladas en un gateway ,
convertida a forma digital y transportadas a través de un
protocolo Simple Packet Transport Relay (SPRT) a otro
gateway.
Cuando llega al otro gateway, se vuelve a crear la señal
de módem y remodulada, y luego pasa al módem del
equipo de recepción.
SPRT es un protocolo que viaja a través del protocolo de
datagramas de usuario (UDP).
Al final de la sesión de módem, los puertos de

voz vuelven a la configuración anterior, igual
que los DSPs y códec de voz.
Este método utiliza menos ancho de banda
(Real-Time Transport Protocol [RTP] no es
necesario) y es mucho menos sensible a la
inestabilidad y desajustes cronometraje de
módem de paso a través.
217
Modem Pass-Through
Cuando un gateway detecta un tono de módem, conmuta la
llamada a un códec de alto ancho de banda.
El tráfico de módem, todavía en forma PCM, viaja en banda
sobre VoIP usando G.711 sin VAD.
Este método de transporte de tráfico de módem se realiza a
un flujo constante de 64 kbps (carga útil) de extremo a
extremo.
Es muy sensible a la pérdida de paquetes, fluctuación de

fase, y la latencia en la red IP, aunque redundancia de
paquetes se puede utilizar para mitigar los efectos de la
pérdida de paquetes.
La redundancia de paquetes es definida en la RFC 2198, y
describe una forma en la que RTP lleva el audio de módem.
Los paquetes redundantes son enviados por si hay pérdida
de paquetes.
Este esquema, obviamente, produce una sobrecarga
significativa, y puede no sea aceptable en todas las
aplicaciones.
Puede activar o desactivar la redundancia de paquetes
durante la configuración del módem pass through.
218
Modem Pass-Through
Modem/POS Gateway Gateway Módem/POS
Red IP
T.30 Llamado de voz T.30

Tono CED
Mensaje DIS
INVITE (G.711A / SDP)
200 OK (SDP)
ACK
RTP en paquetes UDP
2do. INVITE en la
negociación
219
Negociación Modem Pass-Through
<--INVITE sip:65829020@10.178.208.137:5060 SIP/2.0
From: "6004433030"<sip:6004433030@telefonicachile.cl:5060>;tag=1019150314-1372171738378
To: "65829020"<sip:65829020@telefonicachile.cl:5060>;tag=14d8d90-ab2d089-13c4-50029-d0-
72e9f429-d0
Call-ID: 1495468-ab2d089-13c4-50029-d0-67a443db-d0
CSeq: 1038583784 INVITE
Via: SIP/2.0/UDP 172.22.16.35:5060;branch=z9hG4bKmj92lg3068sh5nksm4c0sbtppf8k3.1
Supported:
Accept: application/media_control+xml,application/sdp
Max-Forwards: 9
Content-Length: 190
v=0
s=-
c=IN IP4 172.22.16.35
t=0 0
m=audio 42296 RTP/AVP 8
a=gpmd:8 vbd=yes
a=silenceSupp:off - - - -
a=ptime:20
220
Negociación Modem Pass-Through
-->SIP/2.0 200 OK
From: "6004433030"<sip:6004433030@telefonicachile.cl:5060>;tag=1019150314-1372171738378
To: "65829020"<sip:65829020@telefonicachile.cl:5060>;tag=14d8d90-ab2d089-13c4-50029-d0-72e9f429-d0
Call-ID: 1495468-ab2d089-13c4-50029-d0-67a443db-d0
CSeq: 1038583784 INVITE
Via: SIP/2.0/UDP 172.22.16.35:5060;branch=z9hG4bKmj92lg3068sh5nksm4c0sbtppf8k3.1
Contact: <sip:65829020@10.178.208.137:5060>
X-Serialnumber: CP1121RAF6B
Content-Length: 224
v=0
o=789vn_v3 946688711 946688712 IN IP4 10.178.208.137
s=-
c=IN IP4 10.178.208.137
t=0 0
m=audio 1074 RTP/AVP 8 97
a=fmtp:8 vad=no
a=ptime:20
a=fmtp:97 0-15
221
Modem Pass-Through (Recom. V.152)
SIP Phone (UAS)
SIP Phone (UAC)
INVITE (g729 g711A PCMA)

POS
Transbank 100 Trying
180 Ringing
200 OK (g729 g711A PCMA)
ACK
RTP (PCMA) Switch on

RTP (PCMA) the flight
BYE
200 OK
222
Modem Pass-Through (Recom.v.152)
Switch on the
flaigh
223
En el flujo SIP columna protocolo RTP se

puede observar el cambio de Media de
PT=ITU-T G.711 PCMA a PT=PCMA.
Esa función se llama Switch on the Flaigh
Al seleccionar el paquete RTP PT=PCMA,

se puede observar los atributos del Real-
Time Transport Protocol, especificamente
la línea Payload type: PCMA (96) y otras
características adicionales, como
Sequence number, Timestamp, etc.
224
225
Estándares SIP
226
SIP Standards
Sólo una muestra de los trabajos de normalización del IETF …
IETF RFCs http://ietf.org/rfc.html
RFC 3261 Core SIP specification – obsoletes RFC2543
RFC 2327 SDP – Session Description Protocol
RFC 1889 RTP - Real-time Transport Protocol
RFC 2326 RTSP - Real-Time Streaming Protocol
RFC 3262 SIP PRACK method – reliability for 1XX messages
RFC 3263 Locating SIP servers – SRV and NAPTR
RFC 3264 Offer/answer model for SDP use with SIP
227
SIP Standards (cont.)
RFC 3265 SIP event notification – SUBSCRIBE and NOTIFY
RFC 3266 IPv6 support in SDP
RFC 3311 SIP UPDATE method – eg. changing media
RFC 3325 Asserted identity in trusted networks
RFC 3361 Locating outbound SIP proxy with DHCP
RFC 3428 SIP extensions for Instant Messaging
RFC 3515 SIP REFER method – eg. call transfer
SIMPLE IM/Presence - http://ietf.org/ids.by.wg/simple.html
SIP authenticated identity management -

http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-02.txt
228
04
Servicios
229
Voice Service
Home/Enterprise
230
Servicio VoIP
231
Consideraciones Generales
Definiciones de red
PVC/VLAN.
Ancho de banda.
Códec / Atributos.
IP Servidor Proxy.
Plataforma de voz (MGC).
Tipos de acceso (DSLAM/OLT).
Interacción con la red PSTN.
Definiciones de los Gateway de voz

Puertas FXS.
UPS.
Códec / Atributos.
Dial plan.
Tonos audibles.
Servicios.
232
SIP Trunk Service
233
Servicio SIP Trunk
Generic
Softswitch
SIP Ethernet
NGN
MG
SBC
PSTN
E1/R2
E1/PRI
MG
MG = Media Gateway
234
Consideraciones Generales
Definiciones de red
VLAN.
Ancho de banda.
Códec / Atributos.
IP Proxy.
IP LAN Cliente
Plataforma de voz.
Tipos de acceso.
Interacción con la red PSTN.
Definición de las Soluciones
Centralizadas.
Hosteadas.
Telefonía on Demand
Etc.
235
RFC-3261: Contact
El encabezado del campo Contact proporciona un SIP o SIPS URI que se pueden
utilizar para contactar a esa instancia específica del UA para las solicitudes
posteriores.
El campo de cabecera Contact debe estar presente y contener exactamente un SIP o
SIPS URI en cualquier solicitud que puede resultar en el establecimiento de un
diálogo.
Para los métodos definidos en esta especificación, esta incluye solamente la petición
INVITE.
Para estas peticiones, el alcance del Contact es global. Es decir, el valor del campo
de encabezado Contact contiene el URI en el que el UA desea recibir las solicitudes, y
este URI debe ser válido incluso si se utiliza en solicitudes posteriores fuera de
cualquier diálogo.
Si la petición URI o el valor del campo de la cabecera superior de Ruta contiene una
SIPS URI, el campo de cabecera Contact deberá contener una URI SIPS como
encuentro.
El campo de la cabecera Contact proporciona un SIP o SIPS URI que se pueden
utilizar para contactar en esa instancia específica al UA para las solicitudes
posteriores .
236
Consideraciones SIP (Contact)
237
RFC-5806: Diversion
Extensión del protocolo SIP
Redes legacy el mensaje es enviado en la señalización ISDN/ISUP
(ISDN User Part).
La cabecera Diversion permite la implementación de la información
lógica desde que fue desviado el llamado.
Proporciona la capacidad para que el AU SIP llamado pueda ser
identificado de donde se desvío la llamada.
238
Consideraciones SIP (Diversion)
239
05
Laboratorios
240
Laboratorio 1
Objetivo
El alumno será capaz de cargar software analizador de protocolos
(Wireshark)
El alumno será capaz de interpretar e identificar los mensajes y
atributos del protocolo SIP.
Actividad
Analizar en forma individual archivo con captura para analizar y
comentar.
241
Laboratorio 2
Objetivo
Actividad.
Cada alumno en forma individual analizara muestras de traces y
deberá dejar por escrito el análisis.
242
Laboratorio 3
Objetivo
Actividad
Trabajo grupal
A cada grupo se le entregara archivo con captura defectuosa,
para su análisis y comentar.
243
Laboratorio 4
Objetivo
El alumno será capaz de cargar y configurar softphone con
parámetros que serán entregados.
Actividad
Cargar en PC software sofphone
Configurar softphone
Tomar traces de los eventos de llamadas de entrada y salida.
Cambiar parámetros de:
IP Proxy
Domain
Usersip
Password
Tomar traces.
244
Test Final del Curso
Objetivo
El alumno en forma individual, será capaz de responder las
incógnitas planteadas en test escrito, aplicando los conocimientos
adquiridos durante la etapa de instrucción.
245
Gracias

Curso Protocolo SIP

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Curso Protocolo SIP

Загружено:

Авторское право:

Доступные форматы

Protocolo SIP

Session Initiation Protocol

Razón Social: Telefónica

Network Server (NS): Lógica de Ruteo y Control, definición

Media Server (MS): Recursos de Multimedia, IVR y Audio

Conferencing Server (CS): Permite realizar audio

E-Mail Server (EMS): Permite Almacenar los mensajes de

Web Server (WS): Permite las conexiones vía Web

Razón Social: Telefónica

Call Agent Cisco Unified

Residential Gateway Trunking Gateway

* Conexión de teléfonos * Conexión de canales

FXS = Foreign Exchange Station

Protocolo Señalización Skinny

Razón Social: Telefónica

El Session Initiation Protocol (SIP) es un protocolo de

Esta basado sobre una arquitectura cliente-servidor, en el

IETF RFC 3261.

IERF: Internet Engineering Task Force

RFC: Requests for Comments

Determina la localización del punto final del destino.

Determina la capacidad de la media del punto final del

Determina la disponibilidad del punto final del destino.

Establece una sesión entre el origen y el punto final del

Maneja la transferencia y terminación de llamados

-->REGISTER sip:10.22.16.35:5060;transport=UDP SIP/2.0

<--INVITE sip:228645049@10.160.144.137:5060 SIP/2.0

La localización del usuario final puede ser dinámicamente

El servidor de Localización puede usar uno o mas protocolos, para

Configuración del Dial-plan directamente sobre el gateway.

Traducciones definidas por el gateway.

Soporte avanzado para la integración de sistemas de otros

Interoperabilidad con gateways de voz de otros fabricantes.

Soporta dispositivos finales de otros fabricantes (teléfonos SIP)

Cliente agente de usuario (UAC): Una aplicación cliente que inicia

Servidor de agente de usuario (UAS): Una aplicación de servidor que

Desde un punto de vista arquitectónico, los componentes físicos de una

Phones : Un acto de telefonía IP como un UAS o UAC de

Softphone, gateway y teléfonos IP, SIP inician peticiones

Softphone y teléfonos IP no son configurados sobre los

Gateways: Un gateway actúa como UAS o UAC y

Proporciona al cliente información sobre el siguiente salto

La UA vuelve a dirigir la invitación para el servidor

El servidor puede ser otro servidor de red o un UA.

Recibe las solicitudes de los agente de usuario SIP que

Servidores Registro a menudo se encuentran cerca o

Un B2BUA es un tipo de UA que recibe requerimientos SIP, los

Nota: Además, los servidores SIP pueden interactuar

Cliente: Lado que envía una petición.

Servidor: Lado que responde a una petición recibida.

Transacción: petición + [respuesta (s) provisional (es)] + respuesta

Session Description Protocol Version (v)

Method: This specification defines six methods: REGISTER for registering

Request-URI: The Request-URI is a SIP or SIPS URI or a general URI (RFC

SIP-Version: Both request and response messages include the

REFER Usado para transferencia de llamadas

Utilizado por un Agente de Usuario para establecer una

UPDATE Usado para indicar el estado de una sesión

Session Description Protocol Version (v)

The Status-Code is a 3-digit integer result code that indicates the

Application RSTP SIP RTP DNS

Network TCP UDP

Physical / Data Link Ethernet