voz sobre ip (voip) - unlu€¦ · voz sobre ip (voip) - 2019 - laboratorio de redes recuperación...
TRANSCRIPT
Voz sobre IP(VoIP)
- 2019 -
Laboratorio de REDESRecuperación de Informacióny Estudios de la Web
Administración y Gestión de RedesLic. en Sistemas de Información
Equipo docente:
Fernando Lorge ([email protected])
Santiago Ricci ([email protected])
Alejandro Iglesias ([email protected])
Mauro Meloni ([email protected])
Voz sobre IP
Comunicaciones Telefónicas:
● En telefonía tradicional:
– Señalización: SS7 (Signaling System 7). (ITU-T)
● POTS – Tip&Ring, FXO, FXS, PBX, Líneas, Troncales, Central Office.
● Señalamiento en banda DTMF
Voz sobre IP
Comunicaciones Telefónicas:
● Transmisión:
– PCM (Pulse Code Modulation) ITU-T G.711
● Canal de transmisión tradicional:
– ¿Por qué 64kbps? (Nyquist):
– 8 bits/sample x 8000 samples/sec
– DS0 – Digital Signal 0
Voz sobre IP
Comunicaciones Telefónicas sobre IP:
Arquitectura:
1)Señalización (Signaling o Call Management)
2)Transmisión de datos.
3)Soporte
Voz sobre IP
Comunicaciones Telefónicas sobre IP:
1)Señalización:– Localización– Establecimiento de llamadas (call setup)– Características de la sesión– Terminación de llamadas
2)Transmisión:– Encapsulamiento de datos de audio (y video)– Secuenciamiento, Marcas de tiempo, Identificación
3)Soporte– Autoconfiguración, Calidad de Servicio– Autenticación, Autorización, Contabilidad entre dominios
Voz sobre IP
Transmisión de audio
Procesos– Voz → Audio digital (Analog-to-Digital Conversion-ADC)– Audio digital → Voz (Digital-to-Analog Conversion-DAC)
● CODEC (Codificador Decodificador):
– Convertir señal analógica en una serie de muestras discretas.
– Frecuencia de muestreo– Resolución– Packet Rate
Voz sobre IP
Transmisión de audioSampleo, frecuencia de muestreo, resolución
Voz sobre IP
Transmisión de audioSampleo, frecuencia de muestreo, resolución
Frecuencia de Muestreomedida en Hertz (hz)
(N muestras cada 1 segundo)Ver teorema de Nyquist)
Voz sobre IP
Transmisión de audioSampleo, frecuencia de muestreo, resolución
Am
plitu
d (m
edid
a en
vol
ts)
(val
or r
eal c
on d
ecim
ales
)
Frecuencia de Muestreomedida en Hertz (hz)
(N muestras cada 1 segundo)Ver teorema de Nyquist)
Voz sobre IP
Transmisión de audioSampleo, frecuencia de muestreo, resolución
Cu
anti
zaci
ón
(m
edid
a en
bit
s)(v
alo
r en
tero
de
0 a
2^n
)
Frecuencia de Muestreomedida en Hertz (hz)
(N muestras cada 1 segundo)Ver teorema de Nyquist)
Voz sobre IP
Transmisión de audioSampleo, frecuencia de muestreo, resolución
Voz sobre IP
Transmisión de audioCODECS mas utilizados
● G.711 (PCM): A-law o μ-Law.
● G.722 (SB-ADPCM) Subband Adaptive Differential PCM.
● G.723.1 Dual-Rate Speech Coder for Multimedia Communications
– 5.3Kbps—Algebraic Code Excited Linear Prediction (ACELP)
– 6.3 Kbps—Multipulse Maximum Likelihood Quantization (ML-MLQ)
● G.726 - Adaptive Differential PCM encoding. (ADPCM)
● G.729 - Conjugate Structure ACELP(Algebraic code-excited linear prediction)
● ILBC – Internet Low bitratw Codec (block-independent linear predictive coding)
● Speex – Code-Excited linear prediction (CELP)
● GSM - Linear predictive coding (LPC)
● Opus – RFC 6716 / SILK (Skype) + CELT (Contrained Energy Lapped Transform)
Voz sobre IP
CODEC G.711 (PCM)Sampleo, frecuencia de muestreo, resolución
Cu
anti
zaci
ón
Val
or
de
8 b
its
Frecuencia de Muestreo(8000 muestras por cada segundo)
Voz sobre IP
Transmisión de audioOverhead
● G711 sobre ethernet:
– Codec Payload: 64.000 bps / 50 = 160 B (packet interval 20 msec)
– Overhead capa 2 (Ethernet) = 18 (+ 802.1Q (4)) = 22 B
– Overhead capa 3 (IP) = 20 B
– Overhead capa 4 (UDP: 8 B + RTP: 12 B) = 20 B
– Paquetes por segundo: 50 (1000 msec / 20 msec)
● Total = (160 + 22 + 20 + 20) * 50 = 88.800 bps
Voz sobre IP
Comparación de CODECS
http://www.speex.org/comparison/
Voz sobre IP
Comparación de CODECS – Opus (RFC 6716)
http://opus-codec.org/comparison/
Voz sobre IP
Tiempo de transcodificación en Servidor Asterisk> core show translation // microseconds for one second of data
g723 gsm ulaw alaw g726 adpcm slin lpc10 g729 speex speex16 ilbc g726aal2 g722
g723 15 15 15 15 15 9 15 15 15 23 15 15 17,25
gsm 15 15 15 15 15 9 15 15 15 23 15 15 17,25
ulaw 15 15 9,15 15 15 9 15 15 15 23 15 15 17,25
alaw 15 15 9,15 15 15 9 15 15 15 23 15 15 17,25
g726 15 15 15 15 15 9 15 15 15 23 15 15 17,25
adpcm 15 15 15 15 15 9 15 15 15 23 15 15 17,25
slin 6 6 6 6 6 6 6 6 6 14 6 6 8,25
lpc10 15 15 15 15 15 15 9 15 15 23 15 15 17,25
g729 15 15 15 15 15 15 9 15 15 23 15 15 17,25
speex 15 15 15 15 15 15 9 15 15 23 15 15 17,25
speex16 23,5 23,5 23,5 23,5 23,5 23,5 17,5 23,5 23,5 23,5 23,5 23,5 15
ilbc 15 15 15 15 15 15 9 15 15 15 23 15 17,25
g726aal2 15 15 15 15 15 15 9 15 15 15 23 15 17,25
g722 15,6 15,6 15,6 15,6 15,6 15,6 9,6 15,6 15,6 15,6 15 15,6 15,6
Voz sobre IP
Comunicaciones Telefónicas sobre IP:
● Protocolos de Señalización:
– SIP (IETF)– H323 (ITU-T)– SCCP (Cisco)– AIX (Digium) ...
● Protocolos de Transmisión:
– RTP (IETF) mayormente (junto con RTCP)
H.323
ITU-T Recommendation H.323
● Componentes:
● Terminal● Gatekeeper● Gateway● Multipoint Control Unit
● Protocolos de señalización (subprotocolos):
● H.225 (Call setup)● H.245 (Capabilities negotiation)
● Protocolos de trasmisión de medios:
● RTP/RTCP
H.323
ITU-T Recommendation H.323Proceso general de una llamada
1)Setup: H.225. A lo largo de la llamada se pasa por diferentes estados: Proceeding, Alerting, Connect, Release
2) Negociación de capacidades: H.245. Códecs, medios, puertos, configuraciones específicas, rol master/slave. Sucede inmediatamente después que se “levanta el tubo” en el destinatario.
3) Abrir canal de medios:● RTCP (RTP Control Protocol) define un socket UDP para el canal de medios.● Luego se abre el flujo de UDP/RTP con el códec y el intervalo de paquetes
negociado por H.245.
4) Durante la llamada: RTCP y RTP fluyen.
5) Release: Cuando concluye la llamada, H.225 entra en su estado de Release, poniendo fin al canal de medios, a la sesión de capacidades H.245, y fin a la transacción de accounting de la llamada en el Gatekeeper.
H.323
Pasos de una llamada H.323 exitosa
● Al iniciar el teléfono– Uso opcional de DHCP para obtener una propia dirección IP.– Uso opcional de TFTP para obtener información de configuración.– Descubrimiento del Gatekeeper y registro ante él via H.225 RAS.
● Al realizar una llamada– Se establece una conexión al extremo mediante H.225.– Se negocian los parámetros de la llamada o sesión vía H.245
(H.245 puede transportarse sobre H.225 o no)– Se intercambian los paquetes de voz mediante RTP.– Mediante RTCP se anuncia información de la performance del canal
de voz.– Se cierra la sesión de medios (voz) via H.245.– Se cierra la conexión vía H.225.
H.323
Modo de Operación - Directo
H.245 puede ser incluido en los mensajes H.225
H.323
Modo de operación – Gatekeeper como Proxy
Señalización a través de gatekeeper
H.323
Modo de operación – usando Gateway
Interacción con PSTN
Session InitiationProtocol
Session Initiation Protocol (SIP)RFC 3261
● Componentes:● User Agent (Terminal)● Registrar Server● Proxy Server● Redirect Server
● Protocolos de señalización:● SIP (Call setup)● SDP (Capabilities negotiation)
● Protocolos de trasmisión de medios:● RTP/RTCP
Session InitiationProtocol
Escenario inicial básico
Session InitiationProtocol
Session Initiation Protocol (SIP)RFC 3261
● SIP es un protocolo basado en texto que utiliza el juego de caracteres UTF-8.
● Un mensaje SIP es un requerimiento de un cliente a un servidor o una respuesta de un servidor a un cliente.
User Agent Client (UAC) ↔ User Agent Server (UAS)
● Los mensajes de peticiones y respuestas (Request and Response messages) utilizan el formato básico definido en RFC 2822.
Session InitiationProtocol
Protocolo SIPEstructura de Mensajes:
● Línea inicial (start-line)● Uno o más campos de encabezados (header fields),● Una línea en blanco que indica la finalización de los encabezados,● Opcionalmente un cuerpo de mensaje (message-body)
generic-message = start-line *message-header CRLF [ message-body ]start-line = Request-Line / Status-Line
Session InitiationProtocol
Estructura de Mensajes (Request)
Request-Line = Method <SP> Request-URI <SP> SIP-Version <CRLF>
● Métodos:● REGISTER para registrar información de contacto● INVITE, ACK, and CANCEL para establecimiento de sesiones● BYE para terminar sesiones● OPTIONS para consultar a los servidores por sus capacidades
● Request-URI:● The Request-URI es un URI SIP o SIPS. Indica el usuario o servicio al
cual se destina la solicitud.Formato URI SIP: sip:user@server:port
● SIP-Version: "SIP/2.0"
Session InitiationProtocol
Estructura de Mensajes (Response)
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
● Status code:● 1xx: Provisional – solicitud recibida, se continúa procesando● 2xx: Success – la acción fue recibida exitosamente, comprendida y
aceptada.● 3xx: Redirection – se requiere realizar alguna acción adicional para
completar la petición● 4xx: Client Error – la petición contiene errores de sintaxis o no puede
ser satisfecha por este servidor● 5xx: Server Error – el servidor no puede completar una petición
aparentemente válida● 6xx: Global Failure – la petición no puede ser satisfecha
en ningún servidor
Session InitiationProtocol
Estructura de Mensajes:
● Header Fields:
● header = "header-name" HCOLON header-value *(COMMA header-value)
● field-name: field-value
● Ej.: Route: <sip:[email protected]>,<sip:[email protected]>
● field-name: field-value *(;parameter-name=parameter-value)● Ej.: Contact: <sip:[email protected]>;expires=3600
Session InitiationProtocol
Estructura de Mensajes:
● Bodies (opcional):
● El tipo de contenido (media type) del cuerpo del mensaje DEBE especificarse en el campo de encabezado Content-Type
● Content-Encoding (si se utiliza alguna codificación -compresión-)● Content-Length (longitud)● La interpretación del cuerpo del mensaje depende del método.
Session InitiationProtocol
Establecimiento de llamada VOIP
Session InitiationProtocol
Establecimiento de llamada VOIPEjemplo con Redirect Server
Session InitiationProtocol
Request Message
● Headers mínimos:● To
To: Carol <sip:[email protected]>● From
From: "Bob" <sips:[email protected]> ;tag=a48s● Cseq
CSeq: 4711 INVITE● Call-Id
Call-ID: [email protected]● Max-Forwards
Max-Forwards: 70● Via
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds● Contact (Invite request)
<sip:[email protected]>
Session DescriptionProtocol
Session Description Protocol - SDP(RFC 4566)
“El objetivo de SDP es transmitir información acerca de los flujos en sesiones multimedia para permitir a los destinatarios participar en la sesión”
● Una descripción de sesión SDP incluye:– Nombre de Sesión y propósito (Session Description – Descripción de Sesión)– Tiempo(s) en que la sesión es activa (Time description – Descripción Temporal)– Los medios que componen la sesión (Media description – Descripción de Medios)– Información para recibir esos medios (direcciones, puertos, formatos, etc.)
● Adicionalmente:– Información acerca del bandwidth a utilizar por la sesión– Información de contacto de la persona responsable de la sesión
Session DescriptionProtocol
Session Description Protocol - SDP(RFC 4566)
● Media Information:– El tipo de contenido (video, audio, etc.)– El protocolo de transporte (RTP/UDP/IP, H.320, etc.)– El formato del contenido (H.261 video, MPEG video, etc.)
● Direcciones y puertos:– Unicast:
● La dirección remota● El número de puerto
– Multicast:● La dirección del grupo multicast● El número de puerto
Session DescriptionProtocol
Session Description Protocol - SDP(RFC 4566)
● Una descripción de sesión SDP consiste de líneas de texto de la forma:
<type>=<value>
● <type>: Un carácter
● <value>: Texto estructurado cuyo formato depende de <type>
● Los nombres de campos y atributos de SDP sólo utilizan el subconjunto de caracteres US-ASCII de UTF-8
● Los valores de los atributos y campos textuales pueden utilizar elconjunto de caracteres ISO 10646 completo
Session DescriptionProtocol
Session Description Protocol - SDP(RFC 4566)
● Descripción de Sesión:
– v= (protocol version)– o= (originator and session identifier)– s= (session name)– i=* (session information)– u=* (URI of description)– e=* (email address)– p=* (phone number)– c=* (connection information -- not required if included in all media)– b=* (zero or more bandwidth information lines)– One or more time descriptions– z=* (time zone adjustments)– k=* (encryption key)– a=* (zero or more session attribute lines)– Zero or more media descriptions
Session DescriptionProtocol
Session Description Protocol - SDP(RFC 4566)
● Descripción Temporal:
– t= (time the session is active)– r=* (zero or more repeat times)–
● Descripción de Medio/s: (si existe/n)
– m= (media name and transport address)– i=* (media title)– c=* (connection information -- optional if included at session level)– b=* (zero or more bandwidth information lines)– k=* (encryption key)– a=* (zero or more media attribute lines)
Session DescriptionProtocol
Session Description Protocol - SDP(RFC 4566)
Ejemplo:
v=0o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5s=SDP Seminari=A Seminar on the session description protocolu=http://www.example.com/seminars/[email protected] (Jane Doe)c=IN IP4 224.2.17.12/127t=2873397496 2873404696a=recvonlym=audio 49170 RTP/AVP 0m=video 51372 RTP/AVP 99a=rtpmap:99 h263-1998/90000
Real TimeProtocol
Real Time Protocol – (RTP)RTP Control Protocol (RTCP)
RFC 3550
“Proporciona servicio de entrega extremo-a-extremo para datos con características de tiempo real, como audio y video interactivo”
● Real-time transport protocol (RTP), para transportar datos con propiedades de tiempo real.
● RTP control protocol (RTCP), para monitorear la calidad del servicio.
Real TimeProtocol
Real Time Protocol (RTP) - RTP Control Protocol (RTCP)RFC 3550
● Provee:
● Identificación de tipo de carga
● Numeración de secuencia
● Marcas de tiempo
● Monitoreo de entrega
● Usualmente sobre UDP (puertos no privilegiados 1024-65535):
IPHeader
UDPHeader
Datos (audio, video..)RTPHeader
Real TimeProtocol
Encabezado RTP
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V=VersiónP=PaddingX=ExtensiónCC=Cantidad de CSCRM=MarkerPT=Payload Type (profiles definidos en RFC 3551 o dinámicos)
Real TimeProtocol
RTCP
● RTCP intercambia información de control de manera periódica entre los participantes de una sesión:
● Provee feedback sobre la calidad de la distribución de datos. Permite controlar codificaciones adaptables.
● Provee nombres canónicos para las fuentes.
● Todos los participantes envían paquetes RTCP. La tasa a la que se envían es calculada acorde a la cantidad de participantes.
● Opcionalmente conducir información mínima de control de sesión.
Real TimeProtocol
RTCPTipos de paquetes
● SR, Sender Report: estadísticas de transmisión y recepción de los participantes que son emisores activos. (id de fuente, timestamps, paquetes enviados, datos enviados)
● RR, Receiver Report: estadísticas de recepción de los participantes que no son emisores activos. (id de fuente, paquetes perdidos -porcentaje desde último reporte y acumulado-, max nro de secuencia recibido, jitter, último SR recibido, delay desde último SR)
● SDES, Source Description: descripción de emisores, incluyendo CNAME
● BYE: Indica el final de la participación
● APP: Funciones específicas de aplicación
Mas servicios y protocolos
DHCPAsignación de direcciones
TFTPProvisión de configuración
NTPHora unificada
DNSUso de mnemónicos
Próxima: Intro Seguridad en Redes
Bibliografía:
Packet Guide to Voice over IP: A system administrator's guide to VoIP technologies. Bruce Hartpence. O'Reilly Media. 2013
Switching to VoIP. Ted Wallingford. O'Reilly Media. 2005
Bibliografía