SIP.pdf

5/26/2018 SIP.pdf

1/23

1

7: Multimedia Networking 7-60

SIP: Session Initiation Protocol[RFC 3261]

SIP, visin de largo plazo:

! todas las llamadas telefnicas y videoconferencias serealizarn sobre Internet

! la gente est identificada por sus nombres o direcciones dee-mail, no por nmeros de telfono

! se debe poder localizar a quien se quiere llamar,

independientemente del dispositivo IP que est usando en elmomento


SIP: servicios

! mecanismos paraestablecer una llamada,SIP permite" al llamado saber que

el llamante quiereestablecer una

comunicacin" de forma que se

pongan de acuerdo entipo de media,codificacin

"y finalizar la llamada

! determinar la dir. IPactual del llamado:" mapear identificador

mnemnico a la dir. IPcorriente

! gestin de la llamada:

" agregar nuevos streamsdurante la llamada

" Cambiar codificacindurante la llamada

" invitar a terceros

" transferencia, hold dela llamada

5/26/2018 SIP.pdf

2/23

2


Establecer llamada a una dir. IP conocida!SIP(Alice) mandamensaje INVITEqueindica su puerto, dir. IP,codificacin preferida(PCM !law)

!el mensaje 200 OKdelSIP(Bob) indica su puerto,dir. IP, codificacinpreferida (GSM)

!los mensajes SIP sepueden enviar sobre TCP oUDP; en este casoRTP/UDP

!Puerto SIP por defectoes 5060

time time

Bob'sterminal rings

Alice

167.180.112.24

Bob

193.64.210.89

port 5060

port 38060

Law audio

GSMport 48753

INVITE [email protected]=IN IP4 167.180.112.24m=audio38060RTP/AVP0port 5060

200OK

c=IN IP4 193.64.210.89

m=audio48753RTP/AV

P3

ACKport 5060


Establecimiento de llamada (ms..)

! negociacin del codec:

" Supongamos que Bobno tiene elcodificador PCM !law

" Bob responder conmensaje 606 NOT

ACCEPTABLE,listando sus codecs

" Alice puede enviarnuevo mensajeINVITE, requiriendoun codec diferente

! Rechazo de llamada

" Bob puede rechazarcon respuestaocupado, noestoy, hay quepagar, prohibido

! los datos se puedenenviar sobre RTP uotro protocolo

5/26/2018 SIP.pdf

3/23

3


SIP: ejemplo de mensaje

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 167.180.112.24

From: sip:[email protected]

To: sip:[email protected]

Call-ID: [email protected]

Content-Type: application/sdp

Content-Length: 885

c=IN IP4 167.180.112.24

m=audio 38060 RTP/AVP 0

Notas:! Sintaxis del mensaje: HTTP! sdp = session description protocol! Call-ID es nico para cada llamada

!en este caso no seconoce la dir. IP de Bob.Se necesitan servidoresSIP intermediarios

!Alice manda y recibemensajes SIP usando elpuerto SIP por

defecto 5060!Alice especifica en elcabezal Via:que sucliente SIP usatransporte UDP


Traslacin de nombres y localizacin deusuario

! el llamante solo conoceel nombre o dir. e-maildel llamado

! necesita la dir. IP delhost actual delllamado:" los usuarios se mueven..

" DHCP

" los usuarios tienendiferentes dispositivos(PC, PDA, etc)

! el resultado puede estarbasado en:" hora (trabajo, hogar)

" llamante (queremos que eljefe nos llame a casa?)

" status del llamado (ej.

mandar al correo de voz siest hablando)

Servidores SIP:

! SIP registrar server

! SIP proxy server

5/26/2018 SIP.pdf

4/23

4


SIP Registrar

REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89From: sip:[email protected]

To: sip:[email protected]

Expires: 3600

! cuando Bob lanza su cliente SIP, este enva el mensajeSIP REGISTERal registrar server

(en forma similar a mensajera instantnea)

Register Message:


SIP Proxy

! Alice enva el mensaje INVITEa su proxy server" contiene la direccin sip:[email protected]

! el proxy es responsable del enrutamiento de losmensajes SIP al llamado" posiblemente a travs de mltiples proxies

! el llamado enva la respuesta a travs del mismoconjunto de proxies

! el proxy retorna un menaje de respuesta SIP aAlice" contiene la dir IP de Bob

! proxy anlogo a servidor DNS local

5/26/2018 SIP.pdf

5/23

5


EjemploLlamante [email protected] una llamadaa [email protected]

(1) Jim enva mensajeINVITE al SIP proxyumass(2) Proxy reenva el mensajeal registrar server upenn(3) El servidor upennretorna una respuesta

redirect, indicando quedebe intentar con [email protected]

(4) el proxy umass enva INVITE al registrar eurecom. (5) este reenvaINVITE a 197.87.54.21, donde est levantado el cliente SIP de keith.(6-8) la respuesta SIP es enviada (9) datos enviados directamente entrelos clientes.Nota:falta mostrar un mensaje ACK de SIP

SIP client

217.123.56.89

SIP client

197.87.54.21

SIP proxy

umass.edu

SIP registrar

upenn.edu

SIP

registrar

eurecom.fr

1

2

34

5

6

7

8

9


Comparacin con H.323

! H.323 es otro protocolo desealizacin para sesionesinteractivas en tiempo real

! H.323 es una suiteintegrada y vertical deprotocolos paraconferencia multimedia:

sealizacin, registo,control de admisin,transporte, codecs

! SIP es un nicocomponente. Funciona conRTP, pero no es obligtorio.Se puede combinar conotros protocolos y servicios

! H.323 viene de la ITU(telefona).

! SIP viene de la IETF: usaconceptos de HTTP

" SIP tiene sabor web,mientras que H.323tiene sabor telefona

5/26/2018 SIP.pdf

6/23

6


Captulo 7: agenda

7.1aplicaciones multimediaen red

7.2streaming de audio yvideo almacenado

7.3haciendo lo mejorposible con el serviciobest effort

7.4protocolos paraaplicaciones interactivasen tiempo realRTP,RTCP,SIP

7.5 provisin demltiples clases deservicio

7.6garantas de QoS


Provisin de Mltiples Clases de Servicio

! hasta ahora hemos visto como hacer lo mejor posiblecon el modelo best effort

" modelo de servicio uno para todo

! alternativa: mltiples clases of servicio

" particin del trfico en clases

" tratamiento diferenciado

0111

! granularidad:servicio diferenciadoentre mltiplesclases, NO entreconexionesindividuales

! historia: ToS bits

5/26/2018 SIP.pdf

7/23

7


Mltiples Clases de Servicio: escenario

R1 R2H1

H2

H3

H41.5 Mbps linkR1 output

interfacequeue


Principios de Garantas de QoS

! Escenario: IP phone de 1Mbps comparte un enlace de1.5 Mbps con FTP" rfagas de FTP pueden congestionar el router, y causar

prdidas de audio

" interesa dar prioridad al audio sobre FTP

se necesita marcar los paquetes para que elrouter distinga entre clases de trfico, y polticaspara tratar los paquetes en forma diferenciada

Principio 1

R1 R2

5/26/2018 SIP.pdf

8/23

8



! qu pasa si las aplicaciones se portan mal (p.ej. el audio envams trfico que el declarado)" policing: forzar a la fuente a ajustarse al ancho de banda reservado

! marcar y hacer policing en el borde de la red:" similar a la UNI de ATM (User Network Interface)

proveer proteccin (aislamiento) entre clases de trfico

Principio 2

R1 R2

1.5 Mbps link

1 Mbpsphone

packet marking & policing



! asignar ancho de banda fijo (no compartible) a unflujo: uso ineficientedel recurso si no se usa elancho de banda asignado

hay que proveer aislamiento, manteniendo (si esposible) un uso eficiente de los recursos

Principio 3

R1R2

1.5 Mbps link

1 Mbpsphone

1 Mbps logical link

0.5 Mbps logical link

5/26/2018 SIP.pdf

9/23

9


Mecanismos de Scheduling & Policing

! scheduling:eleccin del prximo paquete a enviar por el enlace! FIFO (first in first out) scheduling:enviar en el orden que llegan

a la cola" poltica de descarte:que paquete descartar ante un arribo si la cola

est llena? Tail drop: descarta paquete recin llegado prioridad: descartar en base a prioridades random: descartar aleatoriamente


Scheduling

Priority scheduling:trasmitir el paquete con mayorprioridad en la cola

! mltiples clases, con prioridades diferentes" la clase se puede caracterizar por la marca del paquete u

otra informacin del encabezado, por ej. IP fuente/dest,puerto, etc.

5/26/2018 SIP.pdf

10/23

10


Scheduling

round robin scheduling:! mltiples clases! bsqueda cclica en las colas de cada clase,

entregando una de c/u (si existe)


Scheduling

Weighted Fair Queuing:

! Round Robin generalizado

! cada clase logra un tiempo de servicio ponderadoen cada ciclo

5/26/2018 SIP.pdf

11/23

11


Policing

Objetivo:limitar el trfico para que no exceda losparmetros acordados

Tres criterios de uso comn:! (Long term) Average Rate:cuntos paquetes se

pueden enviar por unidad de tiempo (en el largo plazo)" pregunta crucial: cul es la longitud del intervalo? 100

paquetes por seg o 6000 paquetes por min tienen el mismopromedio!

! Peak Rate:ej., 6000 pqts por min. (ppm) promedio.;1500 pps de pico

! (Max.) Burst Size:mx. cantidad de paquetes enviadosconsecutivamente (sin tiempo idle entre pqts)


Policing

Token Bucket:limitar la entrada a Burst Size yAverage Rate especificados.

! bucket puede contener b tokens! los tokens se generan a una tasa r token/segsalvo

que se llene el bucket! sobre un intervalo de long. t: cantidad de paquetes

admitidos menor o igual a (r t + b)

5/26/2018 SIP.pdf

12/23

12


Policing

! token bucket & WFQ se pueden combinar paragarantizar una cota superior en el retardo, es decir,garantizar QoS!

WFQ

token rate, r

bucket size, b

per-flow

rate, R

D = b/Rmax

arrivingtraffic


IETF Differentiated Services

! clases de servicio cualitativas" tipos de servicio relativos: Platinum, Gold, Silver

! escalabilidad:funciones simples en el core de lared, y funciones relativamente complejas en elborde de la red (routers o hosts)" sealizar y mantener estador por flujo es

complicado con un gran nmero de flujos! no define clases de servicio, solo proveecomponentes funcionales para construirlas

5/26/2018 SIP.pdf

13/23

13


Edge router:! gestin de trfico por flujo

! marca paquetes in-profile&out-profile

Core router:! gestin de trficopor clase

! buffering & scheduling basadoen marcas en el edge

! se da preferencia a los paquetesin-profile

Arquitectura Diffserv

scheduling

.

.

.

r

b

marking


Marcar paquetes en el router de borde

! class-based marking: paquetes de clases diferentes con marcasdiferenciadas

! intra-class marking: porcin del flujo conforme marcadodiferente que no conforme

! profile:tasa A pre negociada, tamao de bucket B

! Marcas de paquetes basadas en profile por flujo

Posibles usos de marcas:

User packets

Rate A

B

5/26/2018 SIP.pdf

14/23

14


Clasificacin & Acondicionamiento

! los paquetes se marcan con el Type of Service(TOS) en IPv4, y Traffic Class en IPv6

! 6 bits usados para el Differentiated Service CodePoint (DSCP), que determina PHB que recibir elpaquete

! 2 bits sin uso


Clasificacin & Acondicionamiento

puede ser deseable limitar la tasa de trfico dealguna clase:

! el usuario declara su traffic profile (ej., tasa,burst size)

! trfico medido, y acondicionado (shaped) si es noconforme

5/26/2018 SIP.pdf

15/23

15


Forwarding (PHB)

! PHB resulta en caractersticas observables(medibles) de la performance de forwarding

! PHB no especifica que mecanismos se deben usarpara asegurar estas carctersticas observables

! Ejemplos:" Clase A lleva x% del ancho de banda del enlace de salida

en intervalos de longitud especificada

" los paquetes de Clase A se envan antes que los paquetesde Clase B


Forwarding (PHB)

PHBs definidos:! Expedited Forwarding:tasa de salida de paquetes

de una clase mayor o igual a una tasa especificada" enlace lgico con una tasa mnima garantizada

! Assured Forwarding:4 clases de trafico"

c/u con un ancho de banda mnimo garantizado" c/u con tres particiones de preferencia de descarte

(drop)

5/26/2018 SIP.pdf

16/23

16


Captulo 7: agenda

7.1aplicaciones multimediaen red

7.2streaming de audio yvideo almacenado

7.3haciendo lo mejorposible con el serviciobest effort

7.4protocolos paraaplicaciones interactivasen tiempo realRTP,RTCP,SIP

7.5provisin demltiples clases deservicio

7.6 garantas de QoS



! de la vida real:no es posible soportar demandas detrfico superiores a la capacidad del enlace

Control de Admisin: la red puede bloquear lallamada (ej., ocupado) si no hay recursos suficientes

Principio 4

R1R2

1.5 Mbps link

1 Mbpsphone

1 Mbpsphone

5/26/2018 SIP.pdf

17/23

17


Escenario de QoS garantizada

! Reserva de recursos" call setup, sealizacin (RSVP)" declaracin de parmetros de

trfico, QoS" control de admisin en c/elemento

" QoS-sensitivescheduling (e.g.,

WFQ)

r

equest/reply


IETF Integrated Services

! arquitectura para proveer QoS garantizada en redes IP paracada aplicacin

! reserva de recursos: routers mantienen informacin deestado (a la VC) de los recursos asignados

! admisin/rechazo de nuevas llamadas

Pregunta:se pueden admitir flujos nuevos congarantas de performance sin violar la QoSgarantizada a los flujos ya admitidos?

5/26/2018 SIP.pdf

18/23

18


Control de Admisin

Nueva sesin debe:! declarar sus requerimientos de QoS

" R-spec:define la QoS requerida! caracterizar el trfico que inectar en la red

" T-spec:define las caractersticas del trfico! protocolo de sealizacin: necesario para

comunicar R-spec y T-spec a los routers (donde la

reserva es requerida)" RSVP


Intserv QoS: Service models [rfc2211, rfc 2212]

Servicio garantizado:! peor caso de arribo de

trfico: fuente con polticaleaky-bucket

! asegura una cotasimple(matemticamente probable)del retardo [Parekh 1992,Cruz 1988]

Servicio de cargacontrolada:

! QoS aproximada a la que serecibira si los elementos dered estuvieran sin carga"

WFQ

token rate, r

bucket size, b

per-flowrate, R

D = b/Rmax

arrivingtraffic

5/26/2018 SIP.pdf

19/23

19


Sealizacin en Internet

connectionless(stateless)

forwarding by IProuters

best effortservice

no networksignaling protocols

in initial IPdesign

+ =

! Nuevo requerimiento:reserva de recursos a lo largode end-to-end path (involucra end system & routers)para la QoS de aplicaciones multimedia

! RSVP:Resource Reservation Protocol [RFC 2205]" permitir a los usuarios comunicar sus requerimientos a la

red en forma robusta y eficiente -> sealizacin!

! antecedente: ST-II [RFC 1819]


Objetivos de diseo de RSVP

1. permitir receptores heterogneos(anchos de bandadiferentes a lo largo de caminos de red)

2. permitir aplicaciones con diferentes requerimientosde recursos

3. debe funcionar en unicast y tambin en multicast,con adaptacin a la membresa de grupos multicast

4. mejorar el enrutamiento multicast/unicast, conadaptacin suave a los cambios:! reestablecimiento de conexiones

5. overhead del protocolo de controllineal con lacantidad de receptores (como mximo)

6. soft state en routers:requiere refresco de estados

7. diseo modularpara tecnologas heterogneas

5/26/2018 SIP.pdf

20/23

20


RSVP no

! especifica como se deben reservar los recursos

! es solo un mecanismo para comunicar lo que senecesita

! determina la ruta de los paquetes

! esta es la funcin de los protocolos de routing

! sealizacin desacoplada del routing

! interacta con el forwarding de paquetes

! separacin de los planos de control (sealizacin) yde datos (forwarding)


Reserva RSVP

R4

R5

R3R2

R1

Host A24.1.70.210

Host B128.32.32.69P

ATH

PATH

PATH

2

2. The Host ARSVP daemon generates aPATHmessage that is sent to the nexthop RSVP router, R1, in the direction ofthe session address, 128.32.32.69.

PATH

3

3. The PATHmessage follows the nexthop path through R5and R4until it getsto Host B. Each router on the pathcreates soft session state with thereservation parameters.

1. An application on Host Acreates asession, 128.32.32.69/4078, bycommunicating with the RSVP daemon onHost A.

1

5/26/2018 SIP.pdf

21/23

21


Reserva RSVP

R4

R5

R3R2

R1

Host A24.1.70.210

Host B128.32.32.69

PATH

PATHPA

TH

PATH

RESV

RESV

RESV

5

5. The Host BRSVP daemon generatesa RESVmessage that is sent to thenext hop RSVP router, R4, in thedirection of the source address,24.1.70.210.

RESV

6

6. The RESVmessage continues to

follow the next hop path through R5andR1until it gets to Host A. Each routeron the path makes a resourcereservation.

4. An application on Host B

communicates with the local RSVPdaemon and asks for a reservation insession 128.32.32.69/4078. Thedaemon checks for and finds existingsession state.

4


RSVP: diagrama funcional

Application

RSVPD

Admissions

Control

Packet

Classifier

Packet

Scheduler

Policy

ControlD

AT

A

DATA

RSVPD

Policy

Control

Admissions

Control

Packet

Classifier

Packet

SchedulerDATA

Routing

Process

Host Router

5/26/2018 SIP.pdf

22/23

22


Reserva RSVP multicast

! emisores y receptores hacen join a grupo multicastgroup" por fuera de RSVP

! sealizacin del emisor a la red" mensaje path :anuncia presencia del emisor a los routers

" path teardown: borra el path state de los routers

! sealizacin del receptor a la red" mensaje reservation:reserva recursos del emisor al receptor

" reservation teardown: borra las reservas

! sealizacin de la red a los end-systems" path error" reservation error


y todo esto, va a funcionar?

! el modelo de servicios integradostiene evidentesproblemas de escala" pero RSVP se usa como mecanismo de sealizacin en

mltiples reas

! el modelo de servicios diferenciadospuede escalarmejor"

pero hay que configurar coherentemente todos los routersde la red (mecanismos de scheduling y policing, PHBs)

! mecanismos para garantizar QoS en redes debackbone: MultiProtocol Label Switching, MPLS" ideas de ATM pero en IP, y con soporte de tecnologas

heterogneas

5/26/2018 SIP.pdf

23/23

23


Captulo 7: resumen

Principios! clasificacin de aplicaciones multimedia! identificacin de servicios de red necesarios por

las aplicaciones! haciendo lo mejor posible con el servicio best

effortProtocolos y Arquitecturas

! protocolos especficos para best-effort! mecanismos para proveer QoS! arquitecturas para QoS

" clases de servicio" QoS garantizada, control de admisin

SIP.pdf

Documents

Transcript of SIP.pdf