Tema 3:
Protocolos de transporte multimedia.
 Requisitos de la red
 Gestión de los recursos: IntServ vs
DiffServ

RSVP
 RTP/RTCP: Transporte de flujos
multimedia
 RTSP: Control de sesión y localización de
medios
 Protocolos para establecimiento y gestión
de sesiones multimedia



SIP
H.323
Asterisk
Thanks to :
RADCOM technologies
H. Shulzrinne
Paul. E. Jones (from packetizer.com)
Transmisión de Datos Multimedia –
http://www.grc.upv.es/docencia/tdm
– Master IC 2007/2008
Transmisión de Datos Multimedia - Master IC 2007/2008
Requisitos de red.
 Se definen 3 parámetros críticos que la red debería
suministrar a las aplicaciones multimedia:
 Productividad (Throughput)
Número de bits que la red es capaz de entregar por unidad
de tiempo (tráfico soportado).
CBR (streams de audio y vídeo sin comprimir)
VBR (ídem comprimido)
– Ráfagas (Peak Bit Rate y Mean Bit Rate)
 Retardo de tránsito (Transit delay)
Mensaje listo
para envío
Envío del primer
bit del mensaje
Retardo
de acceso
2
Primer bit del
mensaje recibido
Ultimo bit del
Mensaje listo
mensaje recibido para recepción
Retardo
Retardo de
de tránsito
transmisión
Retardo extremo-a-extremo
Retardo
de acceso
Transmisión de Datos Multimedia - Master IC 2007/2008
Requisitos de red (II).
 Varianza del retardo (Jitter)
Define la variabilidad del retardo de una red.
1
2
Emisor
3
t
1
D1
2
D2 = D1
3
Receptor
D3 > D1
t
 Jitter físico (redes de conmutación de circuito)
– Suele ser muy pequeño (ns)
LAN jitter (Ethernet, FDDI).
– Jitter físico + tiempo de acceso al medio.
Redes WAN de conmutación de paquete (IP, X.25, FR)
– Jitter físico + tiempo de acceso + retardo de conmutación de paquete en conmutadores de la
3
red.
Transmisión de Datos Multimedia - Master IC 2007/2008
Internet y las aplicaciones multimedia
 ¿Qué podemos añadir a IP para soportar los
requerimientos de las aplicaciones multimedia?
 Técnicas de ecualización de retardos (buffering)
 Protocolos de transporte que se ajusten mejor a las
necesidades de las aplicaciones multimedia:
RTP (Real-Time Transport Protocol) RFC 1889.
RTSP (Real-Time Streaming Protocol) RFC 2326.
 Técnicas de control de admisión y reserva de recursos
(QoS)
RSVP (Resource reSerVation Protocol) RFC 2205
 Arquitecturas y protocolos específicos:
Protocolos SIP (RFC 2543), SDP (RFC 2327), SAP (RFC
2974), etc..
ITU H.323
4
Transmisión de Datos Multimedia - Master IC 2007/2008
Internet Protocols
Slide thanks to Henning Schulzrinne
5
Tema 3:
Protocolos de transporte multimedia.
Requisitos de la red
Gestión de los recursos: IntServ vs
DiffServ
Computer Networking: A
Top Down Approach
Featuring the Internet,
 RSVP
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y localización
de medios
Protocolos para establecimiento y
gestión de sesiones multimedia
 SIP
 H.323
Transmisión de Datos Multimedia –
3rd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2004.
Thanks to :
RADCOM technologies
H. Shulzrinne
Paul. E. Jones (from packetizer.com)
http://www.grc.upv.es/docencia/tdm
– Master IC 2007/2008
Transmisión de Datos Multimedia - Master IC 2007/2008
7
Scheduling And Policing Mechanisms
 scheduling: choose next packet to send on link
 FIFO (first in first out) scheduling: send in order of arrival to queue
 discard policy: if packet arrives to full queue: who to discard?
 Tail drop: drop arriving packet
 priority: drop/remove on priority basis
 random: drop/remove randomly
Transmisión de Datos Multimedia - Master IC 2007/2008
8
Scheduling Policies: more
Priority scheduling: transmit highest priority queued packet
 multiple classes, with different priorities
 class may depend on marking or other header info, e.g. IP
source/dest, port numbers, etc..
Transmisión de Datos Multimedia - Master IC 2007/2008
9
Scheduling Policies: still more
round robin scheduling:
 multiple classes
 cyclically scan class queues, serving one from each class (if
available)
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
Scheduling Policies: still more
Weighted Fair Queuing:
 generalized Round Robin
 each class gets weighted amount of service in each cycle
Transmisión de Datos Multimedia - Master IC 2007/2008
1
1
Policing Mechanisms
 Goal: limit traffic to not exceed declared parameters
 Three common-used criteria:
 (Long term) Average Rate: how many pkts can be sent per unit time (in
the long run)
 crucial question: what is the interval length: 100 packets per sec or 6000
packets per min have same average!
 Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate
 (Max.) Burst Size: max. number of pkts sent consecutively (with no
intervening idle)
Transmisión de Datos Multimedia - Master IC 2007/2008
Policing Mechanisms
Token Bucket: limit input to specified Burst Size and Average Rate.
 bucket can hold b tokens
 tokens generated at rate r token/sec unless bucket full
 over interval of length t: number of packets admitted less than or
equal to (r t + b).
1
2
Transmisión de Datos Multimedia - Master IC 2007/2008
Policing Mechanisms (more)
 token bucket, WFQ combine to provide guaranteed upper bound
on delay, i.e., QoS guarantee!
arriving
traffic
token rate, r
bucket size, b
WFQ
per-flow
rate, R
D = b/R
max
1
3
Transmisión de Datos Multimedia - Master IC 2007/2008
IETF Integrated Services
 architecture for providing QOS guarantees in IP networks for
individual application sessions
 resource reservation: routers maintain state info (a la VC) of
allocated resources, QoS req’s
 admit/deny new call setup requests:
Question: can newly arriving flow be admitted
with performance guarantees while not violated
QoS guarantees made to already admitted flows?
1
4
Transmisión de Datos Multimedia - Master IC 2007/2008
Intserv: QoS guarantee scenario
 Resource reservation
 call setup, signaling (RSVP)
 traffic, QoS declaration
 per-element admission control
request/
reply
 QoS-sensitive
scheduling (e.g.,
WFQ)
1
5
Transmisión de Datos Multimedia - Master IC 2007/2008
1
6
Call Admission
Arriving session must :
 declare its QOS requirement
 R-spec: defines the QOS being requested
 characterize traffic it will send into network
 T-spec: defines traffic characteristics
 signaling protocol: needed to carry R-spec and T-spec to routers
(where reservation is required)
 RSVP
Transmisión de Datos Multimedia - Master IC 2007/2008
Intserv QoS: Service models [RFC2211, RFC2212]
Guaranteed service:
 worst case traffic arrival: leaky-bucketpoliced source
 simple (mathematically provable) bound
on delay [Parekh 1992, Cruz 1988]
arriving
traffic
Controlled load service:
 "a quality of service closely
approximating the QoS that same flow
would receive from an unloaded
network element."
token rate, r
bucket size, b
WFQ
per-flow
rate, R
D = b/R
max
1
7
Transmisión de Datos Multimedia - Master IC 2007/2008
IETF Differentiated Services
Concerns with Intserv:
 Scalability: signaling, maintaining per-flow router state difficult
with large number of flows
 Flexible Service Models: Intserv has only two classes. Also want
“qualitative” service classes
 “behaves like a wire”
 relative service distinction: Platinum, Gold, Silver
Diffserv approach:
 simple functions in network core, relatively complex functions at
edge routers (or hosts)
 Don’t define define service classes, provide functional
components to build service classes
1
8
Transmisión de Datos Multimedia - Master IC 2007/2008
Diffserv Architecture
Edge router:
 per-flow traffic management
 marks packets as in-profile
and out-profile
Core router:
 per class traffic management
 buffering and scheduling based
on marking at edge
 preference given to in-profile
packets
 Assured Forwarding
1
9
r
b
marking
scheduling
..
.
Transmisión de Datos Multimedia - Master IC 2007/2008
Edge-router Packet Marking
 profile: pre-negotiated rate A, bucket size B
 packet marking at edge based on per-flow profile
Rate A
B
User packets
Possible usage of marking:
 class-based marking: packets of different classes marked differently
 intra-class marking: conforming portion of flow marked differently than nonconforming one
2
0
Transmisión de Datos Multimedia - Master IC 2007/2008
2
1
Classification and Conditioning
 Packet is marked in the Type of Service (TOS) in IPv4, and Traffic
Class in IPv6
 6 bits used for Differentiated Service Code Point (DSCP) and
determine PHB that the packet will receive
 2 bits are currently unused
Transmisión de Datos Multimedia - Master IC 2007/2008
2
2
Classification and Conditioning
may be desirable to limit traffic injection rate of some class:
 user declares traffic profile (e.g., rate, burst size)
 traffic metered, shaped if non-conforming
Transmisión de Datos Multimedia - Master IC 2007/2008
2
3
Forwarding (PHB)
 PHB result in a different observable (measurable) forwarding
performance behavior
 PHB does not specify what mechanisms to use to ensure required
PHB performance behavior
 Examples:
 Class A gets x% of outgoing link bandwidth over time intervals of a
specified length
 Class A packets leave first before packets from class B
Transmisión de Datos Multimedia - Master IC 2007/2008
2
4
Forwarding (PHB)
PHBs being developed:
 Expedited Forwarding: pkt departure rate of a class equals or
exceeds specified rate
 logical link with a minimum guaranteed rate
 Assured Forwarding: 4 classes of traffic
 each guaranteed minimum amount of bandwidth
 each with three drop preference partitions
Tema 3:
Protocolos de transporte multimedia.
Requisitos de la red
Gestión de los recursos: IntServ vs
DiffServ
Computer Networking: A
Top Down Approach
Featuring the Internet,
 RSVP
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y localización
de medios
Protocolos para establecimiento y
gestión de sesiones multimedia
 SIP
 H.323
Transmisión de Datos Multimedia –
3rd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2004.
Thanks to :
RADCOM technologies
H. Shulzrinne
Paul. E. Jones (from packetizer.com)
http://www.grc.upv.es/docencia/tdm
– Master IC 2007/2008
Transmisión de Datos Multimedia - Master IC 2007/2008
Signaling in the Internet
connectionless
(stateless)
forwarding by IP
routers
+
best effort
service
=
no network
signaling protocols
in initial IP
design
 New requirement: reserve resources along end-to-end path (end
system, routers) for QoS for multimedia applications
 RSVP: Resource Reservation Protocol [RFC 2205]
 “ … allow users to communicate requirements to network in robust and
efficient way.” i.e., signaling !
 earlier Internet Signaling protocol: ST-II [RFC 1819]
2
6
Transmisión de Datos Multimedia - Master IC 2007/2008
2
7
RSVP Design Goals
1.
2.
3.
4.
5.
6.
accommodate heterogeneous receivers (different bandwidth along
paths)
accommodate different applications with different resource
requirements
make multicast a first class service, with adaptation to multicast
group membership
leverage existing multicast/unicast routing, with adaptation to
changes in underlying unicast, multicast routes
control protocol overhead to grow (at worst) linear in # receivers
modular design for heterogeneous underlying technologies
Transmisión de Datos Multimedia - Master IC 2007/2008
2
8
RSVP: does not…
 specify how resources are to be reserved
 rather: a mechanism for communicating needs
 determine routes packets will take
 that’s the job of routing protocols
 signaling decoupled from routing
 interact with forwarding of packets
 separation of control (signaling) and data (forwarding) planes
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: overview of operation
 senders, receiver join a multicast
group
 done outside of RSVP
 senders need not join group
 sender-to-network signaling
 path message: make sender
presence known to routers
 path teardown: delete sender’s
path state from routers
 receiver-to-network signaling
 reservation message: reserve
resources from sender(s) to
receiver
 reservation teardown: remove
receiver reservations
 network-to-end-system signaling
 path error
 reservation error
2
9
Transmisión de Datos Multimedia - Master IC 2007/2008
3
0
Call Admission
 Session must first declare its QOS requirement and characterize the
traffic it will send through the network
 R-spec: defines the QOS being requested
 T-spec: defines the traffic characteristics
 A signaling protocol is needed to carry the R-spec and T-spec to the
routers where reservation is required;
 RSVP is a leading candidate for such signaling protocol
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP request (T-Spec)
 A token bucket specification
 bucket size, b
 token rate, r
 the packet is transmitted onward only if the number of tokens in the
bucket is at least as large as the packet
 peak rate, p
 p>r
 maximum packet size, M
 minimum policed unit, m
 All packets less than m bytes are considered to be m bytes
 Reduces the overhead to process each packet
 Bound the bandwidth overhead of link-level headers
3
1
Transmisión de Datos Multimedia - Master IC 2007/2008
3
2
Call Admission
 Call Admission: routers will admit calls based on their R-spec and Tspec and base on the current resource allocated at the routers to
other calls.
Transmisión de Datos Multimedia - Master IC 2007/2008
3
3
Integrated Services: Classes
 Guaranteed QOS: this class is provided with firm bounds on
queuing delay at a router; envisioned for hard real-time applications
that are highly sensitive to end-to-end delay expectation and
variance
 Controlled Load: this class is provided a QOS closely
approximating that provided by an unloaded router; envisioned for
today’s IP network real-time applications which perform well in an
unloaded network
Transmisión de Datos Multimedia - Master IC 2007/2008
3
4
R-spec
 An indication of the QoS control service requested
 Controlled-load service and Guaranteed service
 For Controlled-load service
 Simply a Tspec
 For Guaranteed service
 A Rate (R) term, the bandwidth required
 R  r, extra bandwidth will reduce queuing delays
 A Slack (S) term
 The difference between the desired delay and the delay that would be
achieved if rate R were used
 With a zero slack term, each router along the path must reserve R
bandwidth
 A nonzero slack term offers the individual routers greater flexibility in making
their local reservation
 Number decreased by routers on the path.
Transmisión de Datos Multimedia - Master IC 2007/2008
3
5
QoS Routing: Multiple constraints
 A request specifies the desired QoS requirements
 e.g., BW, Delay, Jitter, packet loss, path reliability etc
 Two type of constraints:
 Additive: e.g., delay
 Maximum (or Minimum): e.g., Bandwidth
 Task
 Find a (min cost) path which satisfies the constraints
 if no feasible path found, reject the connection
Transmisión de Datos Multimedia - Master IC 2007/2008
Path msgs: RSVP sender-to-network signaling
 path message contents:
 address: unicast destination, or multicast group
 flowspec: bandwidth requirements spec.
 filter flag: if yes, record identities of upstream senders (to allow packets
filtering by source)
 previous hop: upstream router/host ID
 refresh time: time until this info times out
 path message: communicates sender info, and reverse-path-tosender routing info
 later upstream forwarding of receiver reservations
3
6
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: simple audio conference





H1, H2, H3, H4, H5 both senders and receivers
multicast group m1
no filtering: packets from any sender forwarded
audio rate: b
only one multicast routing tree possible
H3
H2
R1
R2
H1
H5
3
7
R3
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: building up path state
 H1, …, H5 all send path messages on m1:
(address=m1, Tspec=b, filter-spec=no-filter,refresh=100)
 Suppose H1 sends first path message
m1:
m1:
in L1
out
L2 L6
in
L7
out L3 L4
L6
m1: in
out L5
L7
H3
H2
L3
L2
H1
L1
R1
L6
R2
L5
H5
3
8
L7
R3
L4
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: building up path state
 next, H5 sends path message, creating more state in routers
m1:
L6
L1
m1: in
out L1 L2 L6
in
L7
out L3 L4
L5 L6
m1: in
out L5 L6 L7
H3
H2
L3
L2
H1
L1
R1
L6
R2
L5
H5
3
9
L7
R3
L4
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: building up path state
 H2, H3, H5 send path msgs, completing path state tables
m1:
L1 L2 L6
m1: in
out L1 L2 L6
in L3 L4 L7
out L3 L4 L7
L5 L6 L7
m1: in
out L5 L6 L7
H3
H2
L3
L2
H1
L1
R1
L6
R2
L5
H5
4
0
L7
R3
L4
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
4
1
reservation msgs: receiver-to-network signaling
 reservation message contents:
 desired bandwidth:
 filter type:
 no filter: any packets address to multicast group can use reservation
 fixed filter: only packets from specific set of senders can use reservation
 dynamic filter: senders who’s packets can be forwarded across link will
change (by receiver choice) over time.
 filter spec
 reservations flow upstream from receiver-to-senders, reserving
resources, creating additional, receiver-related state at routers
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: receiver reservation example 1
H1 wants to receive audio from all other senders
 H1 reservation msg flows uptree to sources
 H1 only reserves enough bandwidth for 1 audio stream
 reservation is of type “no filter” – any sender can use reserved
bandwidth
H3
H2
L3
L2
H1
L1
R1
L6
R2
L5
H5
4
2
L7
R3
L4
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: receiver reservation example 1
 H1 reservation msgs flows uptree to sources
 routers, hosts reserve bandwidth b needed on downstream links
towards H1
m1: in L1 L2
out L1(b) L2
L6
L6
m1:
L2
H1
b
b
L1
R1
b
L6
b
R2
L5
H5
4
3
L7
L7(b)
L7
L6
L6(b) L7
m1: in L5
out L5
H2
L4
L4
in L3
out L3
b
L7
b
R3
L3
b
L4
H3
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: receiver reservation example 1 (more)
 next, H2 makes no-filter reservation for bandwidth b
 H2 forwards to R1, R1 forwards to H1 and R2 (?)
 R2 takes no action, since b already reserved on L6
L6
m1: in L1 L2
out L1(b) L2(b) L6
m1:
b
L2
H1
b
b
b L1
R1
b
L6
b
R2
L5
H5
4
4
L7
L7(b)
L7
L6
L6(b) L7
m1: in L5
out L5
H2
L4
L4
in L3
out L3
b
L7
b
R3
L3
b
L4
H3
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: receiver reservation: issues
What if multiple senders (e.g., H3, H4, H5) over link (e.g., L6)?
 arbitrary interleaving of packets
 L6 flow policed by leaky bucket: if H3+H4+H5 sending rate exceeds b,
packet loss will occur
L6
m1: in L1 L2
out L1(b) L2(b) L6
m1:
b
L2
H1
b
b
b L1
R1
b
L6
b
R2
L5
H5
4
5
L7
L7(b)
L7
L6
L6(b) L7
m1: in L5
out L5
H2
L4
L4
in L3
out L3
b
L7
b
R3
L3
b
L4
H3
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: example 2
 H1, H4 are only senders
 send path messages as before, indicating filtered reservation
 Routers store upstream senders for each upstream link
 H2 will want to receive from H4 (only)
H3
H2
L3
L2
H1
4
6
L1
R1
L6
R2
L7
R3
L4
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: example 2
 H1, H4 are only senders
 send path messages as before, indicating filtered reservation
in
L1, L6
L2(H1-via-H1
out L6(H1-via-H1
L1(H4-via-R2
in
; H4-via-R2
)
)
)
L4, L7
L3(H4-via-H4
out L4(H1-via-R2
L7(H4-via-H4
)
H3
H2
R2
L2
H1
L1
R1
L7
L6
in
L3
R3
L6, L7
L6(H4-via-R3
out L7(H1-via-R1
4
7
; H1-via-R3
)
)
)
)
L4
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: example 2
 receiver H2 sends reservation message for source H4 at bandwidth b
 propagated upstream towards H4, reserving b
in
L1, L6
L2(H1-via-H1
out L6(H1-via-H1
L1(H4-via-R2
H2
L2
H1
in
;H4-via-R2 (b))
)
)
L4, L7
L3(H4-via-H4 ; H1-via-R2
out L4(H1-via-62 )
L7(H4-via-H4 (b))
H3
b
L1
R1
b
L6
in
R2
b
L7
L6, L7
L6(H4-via-R3 (b))
out L7(H1-via-R1 )
4
8
)
R3
L3
b
L4
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: soft-state
 senders periodically resend path msgs to refresh (maintain) state
 receivers periodically resend resv msgs to refresh (maintain) state
 path and resv msgs have TTL field, specifying refresh interval
in
L1, L6
L2(H1-via-H1
out L6(H1-via-H1
L1(H4-via-R2
H2
L2
H1
in
;H4-via-R2 (b))
)
)
L4, L7
L3(H4-via-H4 ; H1-via-R3
out L4(H1-via-62 )
L7(H4-via-H4 (b))
H3
b
L1
R1
b
L6
in
R2
b
L7
L6, L7
L6(H4-via-R3 (b))
out L7(H1-via-R1 )
4
9
)
R3
L3
b
L4
H4
Transmisión de Datos Multimedia - Master IC 2007/2008
RSVP: soft-state
 suppose H4 (sender) leaves without performing teardown
 eventually state in routers will timeout and disappear!
in
L1, L6
L2(H1-via-H1
out L6(H1-via-H1
L1(H4-via-R2
H2
L2
H1
in
;H4-via-R2 (b))
)
)
L4, L7
L3(H4-via-H4 ; H1-via-R3
out L4(H1-via-62 )
L7(H4-via-H4 (b))
H3
b
L1
R1
b
L6
in
R2
b
L7
L6, L7
L6(H4-via-R3 (b))
out L7(H1-via-R1 )
5
0
)
R3
L3
b
L4
gone
H4
fishing!
Tema 3:
Protocolos de transporte multimedia.
Requisitos de la red
Gestión de los recursos: IntServ vs
DiffServ
Computer Networking: A
Top Down Approach
Featuring the Internet,
 RSVP
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y localización
de medios
Protocolos para establecimiento y
gestión de sesiones multimedia
 SIP
 H.323
Transmisión de Datos Multimedia –
3rd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2004.
Thanks to :
RADCOM technologies
H. Shulzrinne
Paul. E. Jones (from packetizer.com)
http://www.grc.upv.es/docencia/tdm
– Master IC 2007/2008
Transmisión de Datos Multimedia - Master IC 2007/2008
5
2
RTP (Real-time Transport Protocol)
 Se basa en el concepto de sesión: la asociación entre un
conjunto de aplicaciones que se comunican usando RTP
 Una sesión es identificada por:
 Una dirección IP multicast
 Dos puertos: Uno para los datos y otro para control
(RTCP)
 Un participante (participant) puede ser una máquina o
un usuario que participa en una sesión
 Cada media distinto es trasmitido usando una sesión
diferente.
 Por ejemplo, si se quisiera transmitir audio y vídeo
harían falta dos sesiones separadas  Esto permite
a un participante solamente ver o solamente oír
Transmisión de Datos Multimedia - Master IC 2007/2008
RTP (Real-time Transport Protocol)
 Audio-conferencia con multicast y RTP
 Sesión de audio: Una dirección multicast y dos puertos
 Datos de audio y mensajes de control RTCP.
 Existirá (al menos) una fuente de audio que enviará un stream de
segmentos de audio pequeños (20 ms) utilizando UDP.
 A cada segmento se le asigna una cabecera RTP
 La cabecera RTP indica el tipo de codificación (PCM, ADPCM, LPC,
etc.)
 Número de secuencia y fechado de los datos.
 Control de conferencia (RTCP):
 Número e identificación de participantes en un instante dado.
 Información acerca de cómo se recibe el audio.
 Audio y Vídeo conferencia con multicast y RTP
 Si se utilizan los dos medios, se debe crear una sesión RTP
independiente para cada uno de ellos.
5
3
 Una dirección multicast y 2 puertos por cada sesión.
 Existencia de participantes que reciban sólo uno de los medios.
Transmisión de Datos Multimedia - Master IC 2007/2008
5
4
RTP: Mezcladores y traductores
 Mezcladores (Mixers).
 Permiten que canales con un BW bajo puedan participar en una
conferencia. El mixer re-sincroniza los paquetes y hace todas las
conversiones necesarias para cada tipo de canal.
 Traductores (Translators).
 Permiten conectar sitios que no tienen acceso multicast (p.ej.
que están en una sub-red protegida por un firewall)
Transmisión de Datos Multimedia - Master IC 2007/2008
RTP: Formato de mensaje (I)
32 bits
V PX
CC M
PT
Sequence number
Timestamp
Synchronization Source (SSRC) ID
Contributing Source (CSRC) ID
V: versión; actualmente es la 2
P: si está a 1 el paquete tiene bytes de relleno (padding)
X: presencia de una extensión de la cabecera
5
5
Transmisión de Datos Multimedia - Master IC 2007/2008
RTP: Formato de mensaje (II)
32 bits
V PX
CC M
PT
Sequence number
Timestamp
Synchronization Source (SSRC) ID
Contributing Source (CSRC) ID
CC: Identifica el número de CSRC que contribuyen a los datos
M: Marca (definida según el perfil)
PT: Tipo de datos (según perfil)
5
6
Transmisión de Datos Multimedia - Master IC 2007/2008
RTP: Formato de mensaje (III)
32 bits
V PX
CC M
PT
Sequence number
Timestamp
Synchronization Source (SSRC) ID
Contributing Source (CSRC) ID
Sequence number: Establece el orden de los paquetes
Timestamp: Instante de captura del primer octeto del campo de datos
SSRC: Identifica la fuente de sincronización
CSRC: Fuentes que contribuyen
5
7
Transmisión de Datos Multimedia - Master IC 2007/2008
5
8
RTP header definition
/*
* RTP data header
*/
typedef struct {
unsigned int version:2;
unsigned int p:1;
unsigned int x:1;
unsigned int cc:4;
unsigned int m:1;
unsigned int pt:7;
u_int16 seq;
u_int32 ts;
u_int32 ssrc;
u_int32 csrc[1];
} rtp_hdr_t;
Transmisión de Datos Multimedia - Master IC 2007/2008
5
9
RTP y las aplicaciones
 La especificación de
RTP para una
aplicación particular va
acompañada de:
 Un perfil (profile) que
defina un conjunto de
códigos para los tipos
de datos transportados
(payload)
 El formato de
transporte de cada uno
de los tipos de datos
previstos
Ej.: RFC 1890 para audio y vídeo
PT
encoding audio/video clock rate channels
name
(A/V)
(Hz)
(audio)
______________________________________________
0
PCMU
A
8000
1
1
1016
A
8000
1
2
G721
A
8000
1
3
GSM
A
8000
1
...
34-71 unassigned
?
72-76 reserved
N/A
N/A
N/A
77-95 unassigned
?
96-127 dynamic
?
PCMU
Corresponde a la recomendación CCITT/ITU-T
G.711. El audio se codifica con 8 bits por
muestra, después de una cuantificación
logarítmica. PCMU es la codificación que se
utiliza en Internet para un media de tipo
audio/basic.
Transmisión de Datos Multimedia - Master IC 2007/2008
RTCP (RTP Control Protocol)
 RTCP se basa en envíos periódicos de paquetes de
control a los participantes de una sesión RTP
 Permite realizar una realimentación de la calidad de
recepción de los datos (estadísticas).
 Los paquetes de control siempre llevan la
identificación de la fuente RTP: CNAME
Asociar más de una sesión a un mismo fuente
(sincronización).
 El envío de estos paquetes debe ser controlado por
cada participante (sistema ampliable).
 Control de sesión (opcional)
Información adicional de cada participante.
Entrada y salida de participantes en las sesión.
Negociación de parámetros y formatos.
6
0
Transmisión de Datos Multimedia - Master IC 2007/2008
6
1
RTCP (RTP Control Protocol)
 RTCP permite controlar el trafico que no se auto-limita
(p.ej cuando el número de fuentes aumenta)
 Para ello se define el ancho de banda de la sesión. RTCP
se reserva el 5% (bwRTCP)
 A cada fuente se le asigna 1/4 de bwRTCP
 El intervalo entre cada paquete RTCP es > 5 sec
Transmisión de Datos Multimedia - Master IC 2007/2008
RTCP (RTP Control Protocol)
 Formato de un paquete RTCP:
 Existen distintos tipos de paquetes RTCP:
SR (Sender Report): Informes estadísticos de transmisión y
recepción de los elementos activos en la sesión.
RR (Receiver Report): Informes estadísticos de recepción
en los receptores.
SDES (Source Description): Información del participante
(CNAME, e-mail, etc).
BYE: Salida de la sesión.
APP: Mensajes específicos de la aplicación.
 Cada paquete RTCP tiene su propio formato.
Su tamaño debe ser múltiplo de 32 bits (padding).
Se pueden concatenar varios paquetes RTCP en uno
(compound RTCP packet).
6
2
Transmisión de Datos Multimedia - Master IC 2007/2008
RTCP: Mensajes SR
32 bits
Sender
info
Report
block 1
6
3
RC
PT=SR=200
Longitud
SSRC del sender
NTP timestamp msw
NTP timestamp lsw
RTP timestamp
Contador de los paquetes del sender
cabecera V P
Contador de los bytes del sender
SSRC_1
Frac perd
Total paquetes perdidos
Num sec más alto recibido
Jitter de inter-llegada
Ultimo SR (LSR)
Retraso del último SR (LSR)
Transmisión de Datos Multimedia - Master IC 2007/2008
6
4
RTCP: Cálculo del Jitter
 Es una estimación de la variancia del tiempo de interllegada de los paquetes RTP
D(i, j)  ( R j  Ri )  (S j  Si )  ( R j  S j )  ( Ri  Si )
 Si  RTP timestamp del paquete i
 Ri  Instante de llegada del paquete i
J i  J i 1   Di 1, i   J i 1 / 16
Tema 3:
Protocolos de transporte multimedia.
Requisitos de la red
Gestión de los recursos: IntServ vs
DiffServ
Computer Networking: A
Top Down Approach
Featuring the Internet,
 RSVP
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y localización
de medios
Protocolos para establecimiento y
gestión de sesiones multimedia
 SIP
 H.323
Transmisión de Datos Multimedia –
3rd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2004.
Thanks to :
RADCOM technologies
H. Shulzrinne
Paul. E. Jones (from packetizer.com)
http://www.grc.upv.es/docencia/tdm
– Master IC 2007/2008
Transmisión de Datos Multimedia - Master IC 2007/2008
6
6
Real-Time Streaming Protocol
RFC 2326
 Tiene la función de un “mando a distancia por la red”
para servidores multimedia
 Permite establecer y controlar uno o más flujos de datos
sincronizados
 NO existe el concepto de conexión RTSP sino de sesión
RTSP
 Además, una sesión RTSP no tiene relación con ninguna
conexión especifica de nivel transporte (p.ej. TCP o
UDP)
 Los flujos de datos no tienen por que utilizar RTP
 Está basado en HTTP/1.1
 Diferencias importantes:
No es stateless
Los clientes y servidores pueden generar peticiones
Transmisión de Datos Multimedia - Master IC 2007/2008
Terminología RTSP
 Conferencia
 Media stream
 Una instancia única
de un medio
continuo:
Un stream audio,
Un stream vídeo
Una “whiteboard”
Voz del
conferenciante
Imagen de las
transparencias
Imagen del
conferenciante
 Presentación:
 Es el conjunto de
uno o más streams,
que son vistos por el
usuario como un
conjunto integrado
6
7
Imagen del
público
Voz del
público
Transmisión de Datos Multimedia - Master IC 2007/2008
RTSP: Ejemplo de una sesión
HTTP GET
Cliente
SETUP
PLAY
RTP audio
RTP vídeo
RTCP
PAUSE
TEARDOWN
6
8
Web
server
descripción de la sesión
Media
server
Transmisión de Datos Multimedia - Master IC 2007/2008
RTSP: Comandos de petición
Request =
Request-Line ;
*( general-header | request-header | entity-header )
CRLF
[ message-body ]
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Method
=
"DESCRIBE“ | "ANNOUNCE" | "GET_PARAMETER" |
"OPTIONS“
| "PAUSE" | "PLAY" | "RECORD" |
"REDIRECT" | "SETUP" | "SET_PARAMETER" |
"TEARDOWN" | extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
6
9
Transmisión de Datos Multimedia - Master IC 2007/2008
RTSP: Mensajes de respuesta
Response =
*(
|
|
Status-Line ;
general-header
response-header
entity-header )
CRLF
[ message-body ]
Status-Line = RTSP-version SP Status-Code SP Reason-Phrase CRLF
Status-Code =
1xx: Información (Comando recibido, procesando,..) |
2xx: Exito (Comando recibido y ejecutado con éxito) |
3xx: Re-dirección (Comando recibido pero aún no completado) |
4xx: Error del cliente (El comando tiene errores de sintaxis) |
5xx: Error del servidor (Error interno del servidor)
7
0
Transmisión de Datos Multimedia - Master IC 2007/2008
RTSP: Una sesión completa (I)
1
2
media server A
4
web server W
cliente C
3
media server V
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
7
1
Transmisión de Datos Multimedia - Master IC 2007/2008
RTSP: Una sesión completa (II)
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
A->C: RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001
C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
V->C: RTSP/1.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
server_port=5002-5003
7
2
Transmisión de Datos Multimedia - Master IC 2007/2008
RTSP: Una sesión completa (III)
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2
Session: 23456789
Range: smpte=0:10:00V->C: RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://video.example.com/twister/video;
seq=12312232;rtptime=78712811
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 2
Session: 12345678
Range: smpte=0:10:00A->C: RTSP/1.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
seq=876655;rtptime=1032181
7
3
Transmisión de Datos Multimedia - Master IC 2007/2008
RTSP: Una sesión completa (IV)
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 3
Session: 12345678
A->C: RTSP/1.0 200 OK
CSeq: 3
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 3
Session: 23456789
V->C: RTSP/1.0 200 OK
CSeq: 3
7
4
Tema 3:
Protocolos de transporte multimedia.
Requisitos de la red
Gestión de los recursos: IntServ vs
DiffServ
Computer Networking: A
Top Down Approach
Featuring the Internet,
 RSVP
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y localización
de medios
Protocolos para establecimiento y
gestión de sesiones multimedia
 SIP
 H.323
Transmisión de Datos Multimedia –
3rd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2004.
Thanks to :
RADCOM technologies
H. Shulzrinne
Paul. E. Jones (from packetizer.com)
http://www.grc.upv.es/docencia/tdm
– Master IC 2007/2008
Transmisión de Datos Multimedia - Master IC 2007/2008
Voice-over-Data (VoD) Enables New Applications
 “Click to talk” web sites for e-commerce
 Digital white-board conferences
 Broadcast audio and video over the Internet or a
corporate Intranet
 Integrated messaging: check (or leave) voice mail over
the Internet
 Instant messaging
 Voicemail notifications
 Stock notifications
 Callback notification
 Fax over IP
 Etc.
7
6
Transmisión de Datos Multimedia - Master IC 2007/2008
7
7
Sesion Initiation Protocol
 SIP is end-to-end, client-server session signaling protocol
 SIP’s primarily provides presence and mobility
 Protocol primitives: Session setup, termination, changes,...
 Arbitrary services built on top of SIP, e.g.:
 Redirect calls from unknown callers to secretary
 Reply with a webpage if unavailable
 Send a JPEG on invitation
 Features:





Textual encoding (telnet, tcpdump compatible).
Programmability.
Post-dial delay: 1.5 RTT
Uses either UDP or TCP
Multicast/Unicast comm. support
Transmisión de Datos Multimedia - Master IC 2007/2008
Where’s SIP
Application
Transport
Network
Physical/Data Link
7
8
RTSP
SDP
codecs
SIP
RTP
TCP
UDP
IP
Ethernet
DNS(SRV)
Transmisión de Datos Multimedia - Master IC 2007/2008
7
9
IP SIP Phones and Adaptors
2
1
 Are
true Internet
hosts



Analog phone adaptor
Choice of application
Choice of server
IP appliances
3
 Implementations
 3Com (3)
 Columbia University
 MIC WorldCom (2)
 Mediatrix (1)
4
 Nortel (4)
 Siemens (5)
Palm
control
4
5
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP Components
 User Agents
 UAC (user agent client): Caller application that initiates and sends SIP requests.
 UAS (user agent server): Receives and responds to SIP requests on behalf of
clients; accepts, redirects or refuses calls.
 Server types
 Redirect Server
 Accepts SIP requests, maps the address into zero or more new addresses and returns
those addresses to the client. Does not initiate SIP requests or accept calls.
 Proxy Server
 Contacts one or more clients or next-hop servers and passes the call requests further.
Contains UAC and UAS.
 Registrar Server
 A registrar is a server that accepts REGISTER requests and places the information it
receives in those requests into the location service for the domain it handles.
 Location Server
 Provides information about a caller's possible locations to redirect and proxy servers.
May be co-located with a SIP server.
 Gateways
 A Sip Gateway service allows you to call 'real' numbers from your software or
have a dedicated 'real' telephone number which comes in via VoIP
8
0
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP Trapezoid
DNS
Registrar
SIP
Outgoing
Proxy
Incoming
Proxy
SIP
Originating
User Agent
8
1
Location
Server
DNS
Server
SIP
SIP
SIP
RTP
Terminating
User Agent
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP Triangle?
DNS
Registrar
Incoming
Proxy
SIP
Originating
User Agent
8
2
Location
Server
DNS
Server
SIP
SIP
SIP
RTP
Terminating
User Agent
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP Peer to Peer!
Originating
User Agent
8
3
SIP
RTP
Terminating
User Agent
Transmisión de Datos Multimedia - Master IC 2007/2008
8
4
SIP Methods
 INVITE
Requests a session
 ACK
Final response to the INVITE
 OPTIONS
Ask for server capabilities
 CANCEL
Cancels a pending request
 BYE
Terminates a session
 REGISTER
Sends user’s address to server
Transmisión de Datos Multimedia - Master IC 2007/2008
8
5
SIP Responses
 1XX
Provisional
100 Trying
 2XX
Successful
200 OK
 3XX
Redirection
302 Moved Temporarily
 4XX
Client Error
404 Not Found
 5XX
Server Error
504 Server Time-out
 6XX
Global Failure
603 Decline
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP Flows - Basic
User
A
“Calls”
18.18.2.4
User
B
INVITE: sip:18.18.2.4
180 - Ringing
200 - OK
Answers
ACK
RTP
Talking
Hangs up
Talking
BYE
200 - OK
8
6
Rings
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP INVITE
INVITE sip:e9-airport.mit.edu SIP/2.0
From: "Dennis Baron"<sip:6172531000@mit.edu>;tag=1c41
To: sip:e9-airport.mit.edu
Call-Id: call-1096504121-2@18.10.0.79
Cseq: 1 INVITE
Contact: "Dennis Baron"<sip:6172531000@18.10.0.79>
Content-Type: application/sdp
Content-Length: 304
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE
Supported: sip-cc, sip-cc-01, timer, replaces
User-Agent: Pingtel/2.1.11 (WinNT)
Date: Thu, 30 Sep 2004 00:28:42 GMT
Via: SIP/2.0/UDP 18.10.0.79
8
7
Transmisión de Datos Multimedia - Master IC 2007/2008
8
8
Session Description Protocol
 IETF RFC 2327
 “SDP is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and other
forms of multimedia session initiation.”
 SDP includes:




The type of media (video, audio, etc.)
The transport protocol (RTP/UDP/IP, H.320, etc.)
The format of the media (H.261 video, MPEG video, etc.)
Information to receive those media (addresses, ports, formats and so
on)
Transmisión de Datos Multimedia - Master IC 2007/2008
SDP
v=0
o=Pingtel 5 5 IN IP4 18.10.0.79
s=phone-call
c=IN IP4 18.10.0.79
t=0 0
m=audio 8766 RTP/AVP 96 97 0 8 18 98
a=rtpmap:96 eg711u/8000/1
a=rtpmap:97 eg711a/8000/1
a=rtpmap:0 pcmu/8000/1
a=rtpmap:8 pcma/8000/1
a=rtpmap:18 g729/8000/1
a=fmtp:18 annexb=no
a=rtpmap:98 telephone-event/8000/1
8
9
Transmisión de Datos Multimedia - Master IC 2007/2008
9
0
CODECs
 GIPS Enhanced G.711
 8kHz sampling rate
 Voice Activity Detection
 Variable bit rate
 G.711
 8kHz sampling rate
 64kbps
 G.729
 8kHz sampling rate
 8kbps
 Voice Activity Detection
Transmisión de Datos Multimedia - Master IC 2007/2008
9
1
SIP Flows - Registration
User
B
Registrar
Location
MIT.EDU
MIT.EDU
REGISTER: sip:dbaron@MIT.EDU
401 - Unauthorized
REGISTER: (add credentials)
sip:dbaron@MIT.EDU
Contact 18.18.2.4
200 - OK
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP REGISTER
REGISTER sip:mit.edu SIP/2.0
From: "Dennis Baron"<sip:6172531000@mit.edu>;tag=4561c4561
To: "Dennis Baron"<sip:6172531000@mit.edu>;tag=324591026
Call-Id: 9ce902bd23b070ae0108b225b94ac7fa
Cseq: 5 REGISTER
Contact: "Dennis Baron"<sip:6172531000@18.10.0.79;LINEID=05523f7a97b54dfa3f0c0e3746d73a24>
Expires: 3600
Date: Thu, 30 Sep 2004 00:46:53 GMT
Accept-Language: en
Supported: sip-cc, sip-cc-01, timer, replaces
User-Agent: Pingtel/2.1.11 (WinNT)
Content-Length: 0
Via: SIP/2.0/UDP 18.10.0.79
9
2
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP REGISTER – 401 Response
SIP/2.0 401 Unauthorized
From: "Dennis Baron"<sip:6172531000@mit.edu>;tag=4561c4561
To: "Dennis Baron"<sip:6172531000@mit.edu>;tag=324591026
Call-Id: 9ce902bd23b070ae0108b225b94ac7fa
Cseq: 5 REGISTER
Via: SIP/2.0/UDP 18.10.0.79
Www-Authenticate: Digest realm="mit.edu", nonce="f83234924b8ae841b9b0ae8a92dcf0b71096505216",
opaque="reg:change4"
Date: Thu, 30 Sep 2004 00:46:56 GMT
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, REGISTER, NOTIFY, SUBSCRIBE, INFO
User-Agent: Pingtel/2.2.0 (Linux)
Accept-Language: en
Supported: sip-cc-01, timer
Content-Length: 0
9
3
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP REGISTER with Credentials
REGISTER sip:mit.edu SIP/2.0
From: "Dennis Baron"<sip:6172531000@mit.edu>;tag=4561c4561
To: "Dennis Baron"<sip:6172531000@mit.edu>;tag=324591026
Call-Id: 9ce902bd23b070ae0108b225b94ac7fa
Cseq: 6 REGISTER
Contact: "Dennis Baron"<sip:61725231000@18.10.0.79;LINEID=05523f7a97b54dfa3f0c0e3746d73a24>
Expires: 3600
Date: Thu, 30 Sep 2004 00:46:53 GMT
Accept-Language: en
Supported: sip-cc, sip-cc-01, timer, replaces
User-Agent: Pingtel/2.1.11 (WinNT)
Content-Length: 0
Authorization: DIGEST USERNAME="6172531000@mit.edu", REALM="mit.edu",
NONCE="f83234924b8ae841b9b0ae8a92dcf0b71096505216", URI="sip:mit.edu",
RESPONSE="ae064221a50668eaad1ff2741fa8df7d", OPAQUE="reg:change4"
Via: SIP/2.0/UDP 18.10.0.79
9
4
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP Flows – Via Proxy
Proxy
User
A
“Calls” dbaron
@MIT.EDU
User
B
MIT.EDU
INVITE: sip:dbaron@MIT.EDU
INVITE: sip:dbaron@18.18.2.4
100 - Trying
180 - Ringing
180 - Ringing
200 - OK
Answers
200 - OK
ACK
RTP
Talking
Hangs up
Talking
BYE
200 - OK
9
5
Rings
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP Flows – Via Gateway
Proxy
User
A
“Calls” joe
@MIT.EDU
Gateway
30161
MIT.EDU
INVITE: sip:joe@MIT.EDU
INVITE: sip:38400@18.162.0.25
100 - Trying
Rings
180 - Ringing
180 - Ringing
Answers
200 - OK
200 - OK
ACK
ACK
RTP
Talking
Hangs up
Talking
BYE
BYE
200 - OK
200 - OK
9
6
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP INVITE with Record-Route
INVITE sip:37669@18.162.0.25 SIP/2.0
Record-Route: <sip:18.7.21.118:5080;lr;a;t=2c41;s=b07e28aa8f94660e8545313a44b9ed50>
From: \"Dennis Baron\"<sip:6172531000@mit.edu>;tag=2c41
To: sip:37669@mit.edu
Call-Id: call-1096505069-3@18.10.0.79
Cseq: 1 INVITE
Contact: \"Dennis Baron\"<sip:6172531000@18.10.0.79>
Content-Type: application/sdp
Content-Length: 304
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE
Supported: sip-cc, sip-cc-01, timer, replaces
User-Agent: Pingtel/2.1.11 (WinNT)
Date: Thu, 30 Sep 2004 00:44:30 GMT
Via: SIP/2.0/UDP 18.7.21.118:5080;branch=z9hG4bK2cf12c563cec06fd1849ff799d069cc0
Via: SIP/2.0/UDP 18.7.21.118;branch=z9hG4bKd26e44dfdc2567170d9d32a143a7f4d8
Via: SIP/2.0/UDP 18.10.0.79
Max-Forwards: 17
9
7
Transmisión de Datos Multimedia - Master IC 2007/2008
9
8
SIP Standards







Just a sampling of IETF standards work…
IETF RFCs http://ietf.org/rfc.html
RFC3261
Core SIP specification – obsoletes RFC2543
RFC2327
SDP – Session Description Protocol
RFC1889
RTP - Real-time Transport Protocol
RFC2326
RTSP - Real-Time Streaming Protocol
RFC3262
SIP PRACK method – reliability for 1XX messages
RFC3263
Locating SIP servers – SRV and NAPTR
RFC3264
Offer/answer model for SDP use with SIP
Transmisión de Datos Multimedia - Master IC 2007/2008
SIP Standards (cont.)









RFC3265
SIP event notification – SUBSCRIBE and NOTIFY
RFC3266
IPv6 support in SDP
RFC3311
SIP UPDATE method – eg. changing media
RFC3325
Asserted identity in trusted networks
RFC3361
Locating outbound SIP proxy with DHCP
RFC3428
SIP extensions for Instant Messaging
RFC3515
SIP REFER method – eg. call transfer
SIMPLE
IM/Presence - http://ietf.org/ids.by.wg/simple.html
SIP authenticated identity management 
9
9
02.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-
Tema 3:
Protocolos de transporte multimedia.
Requisitos de la red
Gestión de los recursos: IntServ vs
DiffServ
Computer Networking: A
Top Down Approach
Featuring the Internet,
 RSVP
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y localización
de medios
Protocolos para establecimiento y
gestión de sesiones multimedia
 SIP
 H.323
Transmisión de Datos Multimedia –
3rd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2004.
Thanks to :
RADCOM technologies
H. Shulzrinne
Paul. E. Jones (from packetizer.com)
http://www.grc.upv.es/docencia/tdm
– Master IC 2007/2008
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
Elements of an H.323 System





Terminals
Multipoint Control Units (MCUs)
Gateways
Gatekeeper
Border Elements
Referred to as
“endpoints”
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
Terminals





Telephones
Video phones
IVR devices
Voicemail Systems
“Soft phones” (e.g., NetMeeting®)
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
MCUs
 Responsible for managing multipoint conferences (two or more
endpoints engaged in a conference)
 The MCU contains a Multipoint Controller (MC) that manages the
call signaling and may optionally have Multipoint Processors (MPs)
to handle media mixing, switching, or other media processing
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
Gateways
 The Gateway is composed of a “Media Gateway Controller” (MGC)
and a “Media Gateway” (MG), which may co-exist or exist
separately
 The MGC handles call signaling and other non-media-related
functions
 The MG handles the media
 Gateways interface H.323 to other networks, including the PSTN,
H.320 systems, and other H.323 networks (proxy)
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
Gatekeeper
 The Gatekeeper is an optional component in the H.323 system
which is primarily used for admission control and address resolution
 The gatekeeper may allow calls to be placed directly between
endpoints or it may route the call signaling through itself to perform
functions such as follow-me/find-me and forward on busy
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
Border Elements and Peer Elements
 Peer Elements, which are often co-located with a Gatekeeper,
exchange addressing information and participate in call
authorization within and between administrative domains
 Peer Elements may aggregate address information to reduce the
volume of routing information passed through the network
 Border Elements are a special type of Peer Element that exists
between two administrative domains
 Border Elements may assist in call authorization/authentication
directly between two administrative domains or via a clearinghouse
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
The Protocols (cont)
 H.323 is a “framework” document that describes how the various
pieces fit together
 H.225.0 defines the call signaling between endpoints and the
Gatekeeper
 RTP/RTCP (RFC 3550) is used to transmit media such as audio and
video over IP networks
 H.225.0 Annex G and H.501 define the procedures and protocol for
communication within and between Peer Elements
 H.245 is the protocol used to control establishment and closure of
media channels within the context of a call and to perform
conference control
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
The Protocols (cont)
 H.450.x is a series of supplementary service protocols
 H.460.x is a series of version-independent extensions to the base
H.323 protocol
 T.120 specifies how to do data conferencing
 T.38 defines how to relay fax signals
 V.150.1 defines how to relay modem signals
 H.235 defines security within H.323 systems
 X.680 defines the ASN.1 syntax used by the Recommendations
 X.691 defines the Packed Encoding Rules (PER) used to encode
messages for transmission on the network
Transmisión de Datos Multimedia - Master IC 2007/2008
1
0
Registration, Admission, and Status - RAS
 Defined in H.225.0
 Allows an endpoint to request authorization to place or accept a call
 Allows a Gatekeeper to control access to and from devices under its
control
 Allows a Gatekeeper to communicate the address of other
endpoints
 Allows two Gatekeepers to easily exchange addressing information
Transmisión de Datos Multimedia - Master IC 2007/2008
Registration, Admission, and Status – RAS (cont)
T
RRQ
RCF
GK
(endpoint is registered)
ARQ
ACF
(endpoint may place call)
DRQ
(call has terminated)
DCF
1
1
Symbol Key:
T
Terminal
GK
Gatekeeper
GW
Gateway
1
1
Transmisión de Datos Multimedia - Master IC 2007/2008
The H323 stack
Transmisión de Datos Multimedia - Master IC 2007/2008
H323 Clients
O.S.
Client
Price
Windows
NetMeeting
+/- free
Unix (Linux)
DC-Share
nv
Sun
Sunforum
+/- free
… ...
... ...
... ...
You can find a bigger list at:
http://www.openh323.org/h323_clients.html
1
1
Transmisión de Datos Multimedia - Master IC 2007/2008
1
1
IMPLEMENTACIÓN DE TELEFONÍA IP
EN UNA ORGANIZACIÓN
INTEGRACIÓN CISCO-ASTERISK
Transmisión de Datos Multimedia - Master IC 2007/2008
1
1
CARACTERISTICAS CISCO CALL MANAGER






Solución de Telefonía IP de Cisco
Distribuible
Escalable (30000 lineas/servidor)
Soporta muchos usuarios
Sobre Windows o linux
Soporta gran variedad de teléfonos
1
1
Transmisión de Datos Multimedia - Master IC 2007/2008
PROTOCOLOS
 Sip
 H323
 MGCP (Megaco Protocol)
Transmisión de Datos Multimedia - Master IC 2007/2008
OBJETIVO FINAL
CAMPUS ALCOI
CISCO IP PHONE
CISCO IP PHONE
7960
1
2
ABC
7960
messages
3
directories
1
i
DEF
services
2
ABC
6
4
5
6
MNO
GHI
JKL
MNO
7
*
8
9
7
TUV
WXYZ
PQRS
0
#
*
OPER
directories
i
services
5
JKL
PQRS
messages
3
DEF
settings
4
GHI
8
9
TUV
WXYZ
0
#
settings
OPER
CAMPUS VALENCIA
CISCO IP PHONE
CISCO IP PHONE
7960
7960
1
2
3
ABC
DEF
messages
7
*
5
JKL
6
MNO
1
i
services
4
GHI
PQRS
directories
3
DEF
messages
4
GHI
9
7
WXYZ
PQRS
0
#
*
5
JKL
directories
i
services
settings
8
TUV
OPER
2
ABC
settings
6
MNO
8
9
TUV
WXYZ
0
#
OPER
GW ALCOI
CALL MANAGER
CENTRALITA
TELÉFONOS
158.42.250.141
ASTERISK
158.42.250.173
CAMPUS GANDÍA
GW KISIN
CENTRALITA
TELÉFONOS
158.42.255.237
CENTRALITA
TELÉFONOS
MD-110
GW GANDIA
CISCO IP PHONE
CISCO IP PHONE
7960
1
2
3
ABC
DEF
5
6
GHI
7
PQRS
*
1
1
JKL
MNO
7960
messages
directories
1
i
services
4
3
DEF
5
6
messages
GHI
8
9
7
WXYZ
PQRS
0
#
*
JKL
MNO
8
9
TUV
WXYZ
0
#
OPER
directories
i
services
4
TUV
OPER
2
ABC
settings
settings
1
1
Transmisión de Datos Multimedia - Master IC 2007/2008
FUNCIONAMIENTO DE CALL MANAGER
Transmisión de Datos Multimedia - Master IC 2007/2008
1
1
CONFIGURACIÓN CM
 Interfaz Web
 https://xxxxxx/CCMAdmin/Main.asp
Transmisión de Datos Multimedia - Master IC 2007/2008
1
1
PARTITIONS
 Dividen el conjunto de route patterns en subconjuntos de destinos
alcanzables identificados por un nombre.
 Una partición contiene una lista de Route Patterns
 Facilitan el enrutado de llamadas dividiendo el route plan en
subconjuntos lógicos que se pueden basar en la organización,
localización y tipo de llamada
1
2
Transmisión de Datos Multimedia - Master IC 2007/2008
Partitions
Transmisión de Datos Multimedia - Master IC 2007/2008
1
2
SEARCH SPACES
 Es una lista ordenada de rutas de partición. Estas rutas se asocian a
los dispositivos (teléfonos).
 Determinan las particiones que los dispositivos que hacen una
llamada buscan para que esta llamada se realice
Transmisión de Datos Multimedia - Master IC 2007/2008
1
2
ROUTE PATTERNS
 String de digitos y un conjunto de acciones
 La llamada al destino se hace solo si se marca la secuencia correcta
definida en el route pattern
 Se pueden usan caracteres especiales (x…) para hacer rangos, etc
 Definir route patterns para diferentes tipos de llamadas: nacionales,
sin salida….
Transmisión de Datos Multimedia - Master IC 2007/2008
1
2
ESQUEMA DE NUMERACIÓN





67xxx:
68xxx:
69xxx:
7xxxx:
11xxx:
Teléfonos IP HW (Vera)
SoftPhones
Teléfonos SIP
Teléfonos analógicos (fuera del Call Manager)
Teléfonos móviles
1
2
Transmisión de Datos Multimedia - Master IC 2007/2008
Route patterns
Transmisión de Datos Multimedia - Master IC 2007/2008
1
2
GATEWAYS
 Debe haber uno por cada campus
 Otro que será el router de salida general.
 Coste: 3500-4000 euros
1
2
Transmisión de Datos Multimedia - Master IC 2007/2008
Gateways
Transmisión de Datos Multimedia - Master IC 2007/2008
TRUNK CON ASTERISK
 Es un enlace desde
el Call Manager
al Asterisk:
se enrutan llamadas
de uno al otro
 Se define mediante
la IP del Asterisk
CAMPUS ALCOI
CISCO IP PHONE
CISCO IP PHONE
7960
1
3
DEF
4
GHI
7
*
5
JKL
directories
1
i
services
PQRS
7960
messages
2
ABC
2
3
ABC
DEF
messages
6
services
4
MNO
GHI
8
9
7
TUV
WXYZ
PQRS
0
#
*
OPER
directories
i
settings
5
JKL
settings
6
MNO
8
9
TUV
WXYZ
0
#
OPER
CAMPUS VALENCIA
CISCO IP PHONE
CISCO IP PHONE
7960
7960
1
2
3
ABC
DEF
messages
services
4
GHI
7
PQRS
*
5
JKL
6
MNO
directories
1
i
3
DEF
messages
4
GHI
9
7
WXYZ
PQRS
0
#
*
5
JKL
directories
i
services
settings
8
TUV
OPER
2
ABC
settings
6
MNO
8
9
TUV
WXYZ
0
#
OPER
GW ALCOI
CALL MANAGER
CENTRALITA
TELÉFONOS
158.42.250.141
ASTERISK
158.42.250.173
CAMPUS GANDÍA
GW KISIN
CENTRALITA
TELÉFONOS
158.42.255.237
CENTRALITA
TELÉFONOS
MD-110
GW GANDIA
CISCO IP PHONE
CISCO IP PHONE
7960
1
2
ABC
3
directories
1
i
services
1
2
7960
messages
DEF
2
ABC
3
6
4
5
6
MNO
GHI
JKL
MNO
7
*
8
9
7
TUV
WXYZ
PQRS
0
#
OPER
*
8
9
TUV
WXYZ
0
#
OPER
directories
i
services
5
JKL
PQRS
messages
DEF
settings
4
GHI
settings
1
2
Transmisión de Datos Multimedia - Master IC 2007/2008
Trunk
Transmisión de Datos Multimedia - Master IC 2007/2008
1
2
TELEFONOS
 un identificador, el Device Name (3 caracteres más la dirección
MAC )
 una descripción (ej . la persona asociada)
 el pool al que corresponde
 su estado (registrado o no)
 la dirección IP del teléfono: sólo se muestra si el teléfono está
registrado
1
3
Transmisión de Datos Multimedia - Master IC 2007/2008
Teléfonos
1
3
Transmisión de Datos Multimedia - Master IC 2007/2008
Teléfonos II
Transmisión de Datos Multimedia - Master IC 2007/2008
Teléfonos III
Teléfono Cisco
Teléfono SIP
300 Euros
45-50 Euros
Configuración desde el CM
http://x.y.z.w:9999/
SIP_ADDITIONAL.CONF
1
3
Transmisión de Datos Multimedia - Master IC 2007/2008
1
3
Teléfonos IV















[69001]
<--------- Extensión
username=69001 <--------- Podría ser el login
type=friend
record_out=Adhoc
record_in=Adhoc
qualify=no
port=5060
nat=never
mailbox=666@testmail <------ Su buzón de voz asociado (en el voicemail.conf)
host=dynamic
dtmfmode=info
context=from-internal
canreinvite=no
callerid=device <69001>
language=es
1
3
Transmisión de Datos Multimedia - Master IC 2007/2008
Teléfonos V
Softphone Cisco
IP Communicator
Transmisión de Datos Multimedia - Master IC 2007/2008
1
3
ASTERISK










funcionalidades similares a Call Manager
Soporta SIP, H.323, MGCP, IAX
Se obtiene de : ftp:/ftp.digium.com
Integra casi todos los codecs de audio
Soporte de Telefonía Tradicional
Soporte de Telefonía por Voz IP
APIs para desarrollo de nuevos servicios y aplicaciones
Integración con Bases de Datos
Integración con Aplicaciones ya desarrolladas
Código Abierto: sw libre
1
3
Transmisión de Datos Multimedia - Master IC 2007/2008
CONFIGURACIÓN I
http://asterisk.cc.upv.es
Transmisión de Datos Multimedia - Master IC 2007/2008
1
3
CONFIGURACIÓN II
 Editar directamente ficheros *.conf
indications.conf
extensions.conf
agents.conf
queues.conf
sip.conf
voicemail.conf
asterisk.conf ……….