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.


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





vs DiffServ RSVP




SIP H.323





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





vs DiffServ RSVP




SIP H.323





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


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


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


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


in

out


in

out

L1, L6

L6, L7


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


in

out


in

out

L1, L6

L6, L7


in

out

L4, L7

R2

(b)

(b)

(b)

L1

bb b

b

eventually state in routers will timeout and disappear!

gonefishing!





vs DiffServ RSVP




SIP H.323





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)


Timestamp



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)


Timestamp



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 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


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





vs DiffServ RSVP




SIP H.323





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

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





vs DiffServ RSVP




SIP H.323





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



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!



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

sip:[email protected]

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


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



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




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




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



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



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





vs DiffServ RSVP




SIP H.323





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

Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia. ...

Documents

Transcript of Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia. ...