Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia. ...
-
Upload
reyes-melchor -
Category
Documents
-
view
221 -
download
0
Transcript of Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia. ...
Transmisión de Datos Multimedia - Master IC 2006/2007Transmisión de Datos Multimedia - Master IC 2006/2007
Tema 3: Protocolos de transporte multimedia.
Tema 3: Protocolos de transporte multimedia.
Requisitos de la redGestió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
Thanks to :RADCOM technologiesH. ShulzrinnePaul. E. Jones (from packetizer.com)
Computer Networking: A Top Down Approach
Featuring the Internet, 3rd edition.
Jim Kurose, Keith RossAddison-Wesley, July
2004.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
2
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)
Retardo extremo-a-extremo
Retardo de acceso
Retardo de tránsito
Retardo de transmisión
Mensaje listo para envío
Envío del primer bit del mensaje
Primer bit del mensaje recibido
Ultimo bit del mensaje recibido
Retardo de acceso
Mensaje listo para recepción
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
3
Varianza del retardo (Jitter)Define la variabilidad del retardo de una red.
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 red.
1 2 3
1 2 3D1 D2 = D1 D3 > D1
t
t
Emisor
Receptor
Requisitos de red (II).
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
4
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
5
Internet Protocols
Slide thanks to Henning Schulzrinne
Transmisión de Datos Multimedia - Master IC 2006/2007Transmisión de Datos Multimedia - Master IC 2006/2007
Tema 3: Protocolos de transporte multimedia.
Tema 3: Protocolos de transporte multimedia.
Requisitos de la redGestió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
Thanks to :RADCOM technologiesH. ShulzrinnePaul. E. Jones (from packetizer.com)
Computer Networking: A Top Down Approach
Featuring the Internet, 3rd edition.
Jim Kurose, Keith RossAddison-Wesley, July
2004.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
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 packetpriority: drop/remove on priority basisrandom: drop/remove randomly
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
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..
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
9
Scheduling Policies: still more
round robin scheduling: multiple classes cyclically scan class queues, serving one from each class (if available)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
10
Scheduling Policies: still more
Weighted Fair Queuing: generalized Round Robin each class gets weighted amount of service in each
cycle
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
11
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)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
12
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).
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
13
Policing Mechanisms (more)
token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee!
WFQ
token rate, r
bucket size, b
per-flowrate, R
D = b/Rmax
arrivingtraffic
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
14
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?
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
15
Intserv: QoS guarantee scenario
Resource reservation call setup, signaling (RSVP) traffic, QoS declaration per-element admission control
QoS-sensitive scheduling (e.g.,
WFQ)
request/reply
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
16
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
17
Intserv QoS: Service models [RFC2211, RFC2212]
Guaranteed service: worst case traffic arrival: leaky-
bucket-policed source simple (mathematically provable)
bound on delay [Parekh 1992, Cruz 1988]
Controlled load service: "a quality of service closely
approximating the QoS that same flow would receive from an unloaded network element."
WFQ
token rate, r
bucket size, b
per-flowrate, R
D = b/Rmax
arrivingtraffic
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
18
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
19
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
Diffserv Architecture
scheduling
...
r
b
marking
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
20
Edge-router Packet Marking
class-based marking: packets of different classes marked differently
intra-class marking: conforming portion of flow marked differently than non-conforming one
profile: pre-negotiated rate A, bucket size B packet marking at edge based on per-flow profile
Possible usage of marking:
User packets
Rate A
B
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
21
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
22
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
23
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
24
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
Transmisión de Datos Multimedia - Master IC 2006/2007Transmisión de Datos Multimedia - Master IC 2006/2007
Tema 3: Protocolos de transporte multimedia.
Tema 3: Protocolos de transporte multimedia.
Requisitos de la redGestió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
Thanks to :RADCOM technologiesH. ShulzrinnePaul. E. Jones (from packetizer.com)
Computer Networking: A Top Down Approach
Featuring the Internet, 3rd edition.
Jim Kurose, Keith RossAddison-Wesley, July
2004.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
26
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]
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
27
RSVP Design Goals
1. accommodate heterogeneous receivers (different bandwidth along paths)
2. accommodate different applications with different resource requirements
3. make multicast a first class service, with adaptation to multicast group membership
4. leverage existing multicast/unicast routing, with adaptation to changes in underlying unicast, multicast routes
5. control protocol overhead to grow (at worst) linear in # receivers
6. modular design for heterogeneous underlying technologies
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
28
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
29
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
30
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
31
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
32
Call Admission
Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
33
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
34
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.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
35
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
36
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-to-sender routing info later upstream forwarding of receiver reservations
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
37
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
H2
H5
H3
H4H1
R1 R2 R3
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
38
inout
inout
inout
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
H2
H5
H3
H4H1
R1 R2 R3L1
L2 L3
L4L5
L6 L7
L5 L7L6
L1L2 L6 L3
L7L4m1:
m1:
m1:
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
39
inout
inout
inout
RSVP: building up path state
next, H5 sends path message, creating more state in routers
H2
H5
H3
H4H1
R1 R2 R3L1
L2 L3
L4L5
L6 L7
L5 L7L6
L1L2 L6 L3
L7L4
L5
L6L1
L6
m1:
m1:
m1:
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
40
inout
inout
inout
RSVP: building up path state
H2, H3, H5 send path msgs, completing path state tables
H2
H5
H3
H4H1
R1 R2 R3L1
L2 L3
L4L5
L6 L7
L5 L7L6
L1L2 L6 L3
L7L4
L5
L6L1
L6L7
L4L3L7
L2m1:
m1:
m1:
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
41
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
42
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
H2
H5
H3
H4H1
R1 R2 R3L1
L2 L3
L4L5
L6 L7
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
43
inout
RSVP: receiver reservation example 1
H1 reservation msgs flows uptree to sources routers, hosts reserve bandwidth b needed on
downstream links towards H1
H2
H5
H3
H4H1
R1 R2 R3L1
L2 L3
L4L5
L6 L7
L1L2 L6
L6L1(b)
inout
L5L6 L7
L7L5 (b)
L6
inout
L3L4 L7
L7L3 (b)
L4L2
b
bb
b
bb
b
m1:
m1:
m1:
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
44
inout
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
H2
H5
H3
H4H1
R1 R2 R3L1
L2 L3
L4L5
L6 L7
L1L2 L6
L6L1(b)
inout
L5L6 L7
L7L5 (b)
L6
inout
L3L4 L7
L7L3 (b)
L4L2
b
bb
b
bb
b
b
b
(b)m1:
m1:
m1:
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
45
inout
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
H2
H5
H3
H4H1
R1 R2 R3L1
L2 L3
L4L5
L6 L7
L1L2 L6
L6L1(b)
inout
L5L6 L7
L7L5 (b)
L6
inout
L3L4 L7
L7L3 (b)
L4L2
b
bb
b
bb
b
b
b
(b)m1:
m1:
m1:
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
46
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)
H2 H3
H4H1
R1 R2 R3L1
L2 L3
L4L6 L7
H2 H3
L2 L3
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
47
RSVP: example 2
H1, H4 are only senders send path messages as before, indicating filtered reservation
H2 H3
H4H1
R1 R3L1
L2 L3
L4L6 L7
H2 H3
L2 L3
L2(H1-via-H1 ; H4-via-R2 )L6(H1-via-H1 )L1(H4-via-R2 )
in
out
L6(H4-via-R3 )L7(H1-via-R1 )
in
out
L1, L6
L6, L7
L3(H4-via-H4 ; H1-via-R3 )L4(H1-via-R2 )L7(H4-via-H4 )
in
out
L4, L7
R2
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
48
RSVP: example 2
receiver H2 sends reservation message for source H4 at bandwidth b propagated upstream towards H4, reserving b
H2 H3
H4H1
R1 R3L1
L2 L3
L4L6 L7
H2 H3
L2 L3
L2(H1-via-H1 ;H4-via-R2 )L6(H1-via-H1 )L1(H4-via-R2 )
in
out
L6(H4-via-R3 )L7(H1-via-R1 )
in
out
L1, L6
L6, L7
L3(H4-via-H4 ; H1-via-R2 )L4(H1-via-62 )L7(H4-via-H4 )
in
out
L4, L7
R2
(b)
(b)
(b)
L1
bb b
b
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
49
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
H2 H3
H4H1
R1 R3L1
L2 L3
L4L6 L7
H2 H3
L2 L3
L2(H1-via-H1 ;H4-via-R2 )L6(H1-via-H1 )L1(H4-via-R2 )
in
out
L6(H4-via-R3 )L7(H1-via-R1 )
in
out
L1, L6
L6, L7
L3(H4-via-H4 ; H1-via-R3 )L4(H1-via-62 )L7(H4-via-H4 )
in
out
L4, L7
R2
(b)
(b)
(b)
L1
bb b
b
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
50
RSVP: soft-state
suppose H4 (sender) leaves without performing teardown
H2 H3
H4H1
R1 R3L1
L2 L3
L4L6 L7
H2 H3
L2 L3
L2(H1-via-H1 ;H4-via-R2 )L6(H1-via-H1 )L1(H4-via-R2 )
in
out
L6(H4-via-R3 )L7(H1-via-R1 )
in
out
L1, L6
L6, L7
L3(H4-via-H4 ; H1-via-R3 )L4(H1-via-62 )L7(H4-via-H4 )
in
out
L4, L7
R2
(b)
(b)
(b)
L1
bb b
b
eventually state in routers will timeout and disappear!
gonefishing!
Transmisión de Datos Multimedia - Master IC 2006/2007Transmisión de Datos Multimedia - Master IC 2006/2007
Tema 3: Protocolos de transporte multimedia.
Tema 3: Protocolos de transporte multimedia.
Requisitos de la redGestió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
Thanks to :RADCOM technologiesH. ShulzrinnePaul. E. Jones (from packetizer.com)
Computer Networking: A Top Down Approach
Featuring the Internet, 3rd edition.
Jim Kurose, Keith RossAddison-Wesley, July
2004.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
52
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
53
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. Una dirección multicast y 2 puertos por cada sesión.Existencia de participantes que reciban sólo uno de los medios.Temporización independiente de audio y vídeo.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
54
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)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
55
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
RTP: Formato de mensaje (I)
V P CCX M PT Sequence number
Timestamp
Synchronization Source (SSRC) ID
Contributing Source (CSRC) ID
32 bits
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
56
CC: Identifica el número de CSRC que contribuyen a los datosM: Marca (definida según el perfil)PT: Tipo de datos (según perfil)
RTP: Formato de mensaje (II)
V P CCX M PT Sequence number
Timestamp
Synchronization Source (SSRC) ID
Contributing Source (CSRC) ID
32 bits
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
57
Sequence number: Establece el orden de los paquetesTimestamp: Instante de captura del primer octeto del campo de datosSSRC: Identifica la fuente de sincronizaciónCSRC: Fuentes que contribuyen
RTP: Formato de mensaje (III)
V P CCX M PT Sequence number
Timestamp
Synchronization Source (SSRC) ID
Contributing Source (CSRC) ID
32 bits
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
58
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;
/* * 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;
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
59
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 ?
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 ?
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
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.
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.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
60
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: CNAMEAsociar 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.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
61
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
62
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).
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
63
RTCP: Mensajes SR
V P RC PT=SR=200 Longitud
SSRC del sender
32 bits
NTP timestamp mswNTP timestamp lsw
RTP timestamp
Contador de los paquetes del sender
Contador de los bytes del senderSSRC_1
Frac perd Total paquetes perdidos
Num sec más alto recibidoJitter de inter-llegada
Retraso del último SR (LSR)Ultimo SR (LSR)
Report block 1
Sender info
cabecera
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
64
RTCP: Cálculo del Jitter
Es una estimación de la variancia del tiempo de inter-llegada de los paquetes RTP
Si RTP timestamp del paquete i
Ri Instante de llegada del paquete i
)()()()(),( iijjijij SRSRSSRRjiD
16/,1 11 iii JiiDJJ
Transmisión de Datos Multimedia - Master IC 2006/2007Transmisión de Datos Multimedia - Master IC 2006/2007
Tema 3: Protocolos de transporte multimedia.
Tema 3: Protocolos de transporte multimedia.
Requisitos de la redGestió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
Thanks to :RADCOM technologiesH. ShulzrinnePaul. E. Jones (from packetizer.com)
Computer Networking: A Top Down Approach
Featuring the Internet, 3rd edition.
Jim Kurose, Keith RossAddison-Wesley, July
2004.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
66
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 statelessLos clientes y servidores pueden generar peticiones
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
67
Terminología RTSP
Conferencia Media stream
Una instancia única de un medio continuo:Un stream audio,Un stream vídeoUna “whiteboard”
Presentación: Es el conjunto de
uno o más streams, que son vistos por el usuario como un conjunto integrado
Voz del público
Imagen del conferenciante
Imagen del público
Imagen de las transparencias
Voz del conferenciante
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
68
RTSP: Ejemplo de una sesión
Web server
SETUP
PLAY
PAUSE
TEARDOWN
HTTP GET
descripción de la sesión
RTP audio
RTP vídeo
RTCP
Cliente
Media server
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
69
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
70
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)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
71
RTSP: Una sesión completa (I)
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
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
web server W
cliente C
media server A
media server V
1
3
2
4
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
72
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
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
73
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:00-
V->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:00-
A->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
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Session: 23456789 Range: smpte=0:10:00-
V->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:00-
A->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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
74
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
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
Transmisión de Datos Multimedia - Master IC 2006/2007Transmisión de Datos Multimedia - Master IC 2006/2007
Tema 3: Protocolos de transporte multimedia.
Tema 3: Protocolos de transporte multimedia.
Requisitos de la redGestió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
Thanks to :RADCOM technologiesH. ShulzrinnePaul. E. Jones (from packetizer.com)
Computer Networking: A Top Down Approach
Featuring the Internet, 3rd edition.
Jim Kurose, Keith RossAddison-Wesley, July
2004.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
76
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.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
77
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
78
SIP History
Work began in 1995 in IETF mmusic WG 02/1996: draft-ietf-mmusic-sip-00: 15 ASCII pages, one
request type 12/1996: -01 30 ASCII pages, 2 request types 01/1999: -12 149 ASCII pages, 6 methods 03/1999: RFC 2543, 153 ASCII pages, 6 methods 11/1999: SIP WG formed 11/2000: draft-ietf-sip-rfc2543bis-02, 171 ASCII pages, 6
methods 12/2000: It was recognized that amount of work at SIP
WG was becoming unmanageable; 1 RFC; 18 I-Ds on WG’s agenda; numerous individual submissions
04/2001: Proposal for splitting SIP WG into SIP and SIPPING announced
2001: SIP implementations widely available http://www.cs.columbia.edu/~hgs/sip/implementations.html http://www.pulver.com/sip/products.html
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
79
Where’s SIP
Application
Transport
Network
Physical/Data LinkEthernet
IP
TCP UDP
RTSP SIP
SDP codecs
RTP DNS(SRV)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
80
4
IP SIP Phones and Adaptors
1
3
Analog phone adaptor
Palmcontrol
2
54
Are true Internet hosts Choice of
application Choice of server IP appliances
Implementations 3Com (3) Columbia
University MIC WorldCom (2) Mediatrix (1) Nortel (4) Siemens (5)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
81
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
82
SIP Trapezoid
DNS Server
Location Server
Terminating User Agent
Outgoing Proxy
Originating User Agent
DNS
SIP
SIP
SIP SIP
RTP
Registrar
Incoming Proxy
SIP
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
83
SIP Triangle?
DNS Server
Location Server
Terminating User Agent
Originating User Agent
DNS
SIP
SIP SIP
RTP
Registrar
Incoming Proxy
SIP
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
84
SIP Peer to Peer!
Terminating User Agent
Originating User Agent
SIP
RTP
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
85
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
86
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
87
SIP Flows - Basic
ACK
200 - OK
INVITE: sip:18.18.2.4“Calls”
18.18.2.4
180 - Ringing Rings
200 - OK Answers
BYEHangs up
RTPTalking Talking
User A
User B
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
88
SIP INVITE
INVITE sip:e9-airport.mit.edu SIP/2.0
From: "Dennis Baron"<sip:[email protected]>;tag=1c41
To: sip:e9-airport.mit.edu
Call-Id: [email protected]
Cseq: 1 INVITE
Contact: "Dennis Baron"<sip:[email protected]>
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
89
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)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
90
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
91
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
92
SIP Flows - Registration
200 - OK
REGISTER: sip:[email protected]
401 - Unauthorized
User B MIT.EDUMIT.EDU
Registrar
REGISTER: (add credentials)
MIT.EDUMIT.EDU
Location
Contact 18.18.2.4
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
93
SIP REGISTER
REGISTER sip:mit.edu SIP/2.0
From: "Dennis Baron"<sip:[email protected]>;tag=4561c4561
To: "Dennis Baron"<sip:[email protected]>;tag=324591026
Call-Id: 9ce902bd23b070ae0108b225b94ac7fa
Cseq: 5 REGISTER
Contact: "Dennis Baron"<sip:[email protected];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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
94
SIP REGISTER – 401 Response
SIP/2.0 401 Unauthorized
From: "Dennis Baron"<sip:[email protected]>;tag=4561c4561
To: "Dennis Baron"<sip:[email protected]>;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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
95
SIP REGISTER with Credentials
REGISTER sip:mit.edu SIP/2.0
From: "Dennis Baron"<sip:[email protected]>;tag=4561c4561
To: "Dennis Baron"<sip:[email protected]>;tag=324591026
Call-Id: 9ce902bd23b070ae0108b225b94ac7fa
Cseq: 6 REGISTER
Contact: "Dennis Baron"<sip:[email protected];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="[email protected]", REALM="mit.edu", NONCE="f83234924b8ae841b9b0ae8a92dcf0b71096505216", URI="sip:mit.edu", RESPONSE="ae064221a50668eaad1ff2741fa8df7d", OPAQUE="reg:change4"
Via: SIP/2.0/UDP 18.10.0.79
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
96
SIP Flows – Via Proxy
INVITE: sip:[email protected]“Calls” dbaron
@MIT.EDUINVITE: sip:[email protected]
100 - Trying
180 - Ringing
Rings180 - Ringing
200 - OK Answers
200 - OK
ACK
BYEHangs up
200 - OK
User A
User BMIT.EDUMIT.EDU
Proxy
Talking TalkingRTP
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
97
SIP Flows – Via Gateway
INVITE: sip:[email protected]“Calls” joe
@MIT.EDUINVITE: sip:[email protected]
100 - Trying
ACKACK
User A MIT.EDUMIT.EDU
Proxy
30161Gateway
180 - Ringing
180 - Ringing
Rings
200 - OK
200 - OK
Answers
BYEHangs up
BYE
200 - OK
200 - OK
Talking TalkingRTP
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
98
SIP INVITE with Record-Route
INVITE sip:[email protected] SIP/2.0
Record-Route: <sip:18.7.21.118:5080;lr;a;t=2c41;s=b07e28aa8f94660e8545313a44b9ed50>
From: \"Dennis Baron\"<sip:[email protected]>;tag=2c41
To: sip:[email protected]
Call-Id: [email protected]
Cseq: 1 INVITE
Contact: \"Dennis Baron\"<sip:[email protected]>
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
99
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
100
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 -
http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-02.txt
Transmisión de Datos Multimedia - Master IC 2006/2007Transmisión de Datos Multimedia - Master IC 2006/2007
Tema 3: Protocolos de transporte multimedia.
Tema 3: Protocolos de transporte multimedia.
Requisitos de la redGestió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
Thanks to :RADCOM technologiesH. ShulzrinnePaul. E. Jones (from packetizer.com)
Computer Networking: A Top Down Approach
Featuring the Internet, 3rd edition.
Jim Kurose, Keith RossAddison-Wesley, July
2004.
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
102
Elements of an H.323 System
Terminals Multipoint Control Units (MCUs) Gateways Gatekeeper Border Elements
Referred to as “endpoints”
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
103
Terminals
Telephones Video phones IVR devices Voicemail Systems “Soft phones” (e.g., NetMeeting®)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
104
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
105
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)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
106
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
107
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
108
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
109
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
110
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
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
111
Registration, Admission, and Status – RAS (cont)
T GKRRQ
RCF
ARQ
(endpoint is registered)
ACF(endpoint may place call)
DRQ
DCF(call has terminated) T Terminal
GK Gatekeeper
GW Gateway
Symbol Key:
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
112
H.225.0 Call Signaling
Allows an endpoint to initiate and terminate a call with another endpoint
GW GWSetup
Alerting
Connect
(call is established)
Release Complete(call is terminated)
H.245 Signaling may take place at any point
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
113
Open a channel in
each direction
H.245 Signaling
H.245 is used to negotiate capabilities and to control aspects of the conference between two or more endpoints
GW GWTCS + MSD
TCS + TCS Ack + MSD Ack
TCS Ack + MSD Ack + OLC
OLC Ack + OLC
OLC Ack
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
114
Fast Connect and H.245
Some H.323 calls do not utilize the rich capabilities offered by H.245 and simply media channels using the “Fast Connect” procedures
In this mode, a call may be established with as few as two messages (Setup / Connect)
GW GWSetup
Connect
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
115
An H.323 Stack
RASRTP / RTCP
Packet Network
H.323 Application
H.245
H.225.0Call Signaling
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
116
H323 stack
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
117
Resolving Addresses
A Gatekeeper may resolve addresses in a number of ways Sending a Location Request (LRQ) message to another Gatekeeper Accessing a Peer Element Accessing a back-end database (e.g., LDAP)
Gatekeepers and Peer Elements may query other Gatekeepers and Peer Elements and may exchange address information outside the context of a call
Since a Gatekeeper is not required, endpoints may resolve addresses themselves using, for example, DNS, LDAP, or a local “phonebook” containing static IP addresses
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
118
Using LRQs
TGK
LRQ
GK
GK
ARQ
LRQ
A Gatekeeper may send an LRQ to one ore more Gatekeepers
It may accept any LCF response and utilize that information to satisfy the original ARQ
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
119
Using LRQs with Hierarchical Gatekeepers (cont)
A Gatekeeper may forward an LRQ received on to another Gatekeeper in order to resolve the address
The response may be directed back to the originating Gatekeeper or the intermediate Gatekeeper
TGK
LRQ
GK
ARQ
GK
LRQ
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
120
Using a Border Element
As with hierarchical Gatekeepers, Border Elements may send AccessRequest messages to other Border Elements and indicate where to send a reply
Border Elements may also reply directly to a request by utilizing address information cached from previous exchanges with other Border ElementsT
GK
LRQ
GK/BE
ARQ
GK/BE
AccessRequest
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
121
H.323 Features
Advanced Videoconferencing: Supports advanced videoconferencing features, including Cascading MCUs MCU control over audio and video mixing Chair control Far-end camera control
Standard mechanisms to provide a variety of services, including Call transfer Call forward Call park/pick-up Call Hold Call Waiting Message Waiting Indication Call Completion on Busy / No-Answer Call Intrusion
Support for HTTP-based service control (H.323 Annex K)
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
122
QoS
H.460.9 allows an endpoint to report Quality of Service information to the Gatekeeper, aiding in determine how to route calls
H.323 devices may utilize IETF standards for providing quality of service, including DiffServ and RSVP
Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7Tra
nsm
isió
n d
e D
ato
s M
ult
imed
ia -
Mast
er
IC 2
00
6/2
00
7
123
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