Internet Protocols Multimedia Netw orking for Multimedia T - - PDF document

1 Internet Protocols for Multimedia

DS VT-01 Jerry Eriksson

Multimedia Netw orking

T Animation, voice and video - not only text T Video, Distributed simulation, distribute

work groups

T Multimedia networks may replace

telephone, television, etc

T Challenges - build hardware and software

infrastructure and applications to support multimedia

Outline

T Real-time challenges T Real-time protocols

S RTP, RTCP, RTSP

T QoS

S Definitions S Goals

T Traffic management architectures

S IntServ , Diffserv , RSVP

T VoIP

S H.323 S SIP, some

Real-time Challenges

T Bandwidth T Latency, jitter T Audio and video must be played back at

the rate they were sampled (voice may be even more difficult)

T Multimedia data streams are bursty

Internet

T Primary reason: Platform for most

networking activities

T Integrated data and multimedia service

• ver a single network (investments)

T Not suitable for real-time traffic

S Offers only best-effort quality

Problems to solve

T Provide

S enough bandwidth S multicast to reduce traffic S protocols that handle care of timing issues

R Delay, Jitter

T QoS

S ’guarantee’ quality S Reserve resource on the internet S Transport protocols

T Presentation of the multimedia data T Charging and policing mechaninsm

2 RTP - development

T December 1992, Henning Schulzrinne,

GMD Berlin, published RPT version 1

S see www.cs.columbia.edu/~ hgs/rtp

T Proposed (version 2) as standard

November,1995

Some RTP Implementations

Tool Who Media

NeVoT GMD Fokus Audio vic LBNL Video vat LBNL Audio Rat UCL Audio Rendezvous INRIA A/V NetMeeting Microsoft A/V IP/TV Cisco A/V RM G2 Real A/V

RTP- Real time transport protocols

T IP-based protocol providing

S time-reconstruction S loss detection S security S content identification

T Designed primarily for multicast of real-

time data (also unicast, simplex, duplex)

T Separate Control/Data

Where is RTP reside

T RTP is typically run on top of UDP

S Uses UDP’s multiplexing and checksum

• functions. May be viewed as a sublayer of the

transport layer

T RTP is usually implemented within the

application

S Lost packets and congestion control have to be implemented in the application level

Header fields

Type Sequence number Time- stamp Synch source ID

Miscellaneous fields

7 bits 16 bits 32 bits 32 bits

How does RTP works

T Timestamping - most important information for real- time applications. S The sender timestamp according to the instant t he first octet in the packet was sampled. S The receiver uses timestamp to reconstruct the

• riginal timing

S Also used for synchronize different streams; audio an video in MPEG. ( Application level responsible for the actual synchronization)

3 How does RTP w ork

T Payload type identifier

S specifies the payload format as well as encoding/compression schemes S The application then knows how to interpret the payload

T Source identification

S Identifies the source, not IP adress

RTCP - Real Time Control Protocol (RFC 1889)

T Designed to work together with RTP T In an RTP session the participants

periodically send RTCP packet to give feedback on the quailty of the data.

T Comparable to flow and congestion

control of other transport protocols.

T RTP produces sender and receivers

reports; statistics and packet counts

RTCP packet types; reports

T Recevier (RR)

S SSRC, Packet lost, jitter, timestamps

T Sender (SR)

S SSRC, S NTP Timestamp, wall clock of RTP packet S RTP Timestamp S Intermedia synchronization, number of bytes sent, packet counters

RTCP provides the follow ing services

T QoS monitoring and congestion control

S Primary function: QoS feedback to the application S The sender can adjust its transmission S The receiver can determine if the congestion is local, regional, or global S Network managers can evaluate the network performance for multicast distribution

RTCP provides the follow ing services (Cont)

T Source identification T inter-media synchronization T control information scaling

S Limit control traffic (most 5 % of the overall session traffic)

RTP/RTCP features

T Provides

S end-to-end real- time data delivery (functionality and control mechanisms) S timestamps sequences numbering (up to the application to use it)

T Uses UDP T Provides not

S timely delivery (needs lower layer reservations) S any form of reliability

• r flow/congestion

control (RTCP)

T Not complete - new payload format

4 What is Streaming?

T Streaming breaks data into packets; real-

time data through the transmission, decompressing just like a water stream.

S A client can play the first packet, decompress the second, while receiving the third. S The user can start enjoying the multimedia without waiting to the end of the transmission

RTSP - real time streaming protocol

T Client -server multimedia presentation protocol to enable controlled delivery S provides ”vcr”-style remote control functionality of streamings over IP. S RTSP is an application-level protocol designed to work with RTP (and RSVP) to provide a complete streaming service over internet S It provides means for choosing channels (UDP etc) and delivery mechanisms (RTP) T Developed by RealNetworks , netscape, and columbia university (still an internet draft)

RTSP operations and methods

T RTSP establish and controls streams T A media server provides playback or

recording services

T A client requests continues media data

from the media server

T RTSP is the network is the ”network

remote control” between the server and the client

RTSP provides

T Retrieval of media from media server T Invitation of a media server to a

conference

T Adding media to an existing presentation T Similar services on streamed audio and

video, just as HTTP does for text and graphics

HTTP/RTSP differences

T HTTP stateless protocol; an RTSP server

has to maintain ”session states”

T HTTP is asymmetric; in RTSP both client

and server can issue requests

T It uses URL, like HTTP T visa bild

QoS Definitions

T Qos is a set of technologies

S enables network administrators to manage the effects of congestion on application traffic by using network resources optimally, or S allocate different resourses for different data flows, or S ….

5 QoS classes

T Best-effort - No gurantees at all T Soft QoS - differentiated guarantess T Hard QoS - full guarantees

Resources reservation and prioriations

T Any QoS better than best-effort.

S Routing delays and congestion losses

T Real-time traffic

IP QoS Netw orking - Integrated services

T Defined by an IETF working group to be a key- stone T IS was developed to optimize network and resource utilization which require QoS. T Divided traffic between into different QoS classes. T An internet router must be able to provide an appriopriate QoS for each flow. (according to a service model)

Router function: Traffic control

T Packet scheduler manages forwarding of

different packet streams.

S Service class, queue management, algorithms S Police and shape traffic S implemented where the packets are queued .

Router function: Traffic control

T Packet classifier indentifies packets of an

IP flow in hosts and routers that will receive a certian level of service.

S Each packet is mapped by the classifier into a specific class. (same class, same treatment) S The choice of class is based upon the source and destination, and port number in packet header

Admission control

T Decision algorithms that a router uses to

determine if there are routing resources to accept the requested QoS for a flow

S If the flow is accepted; the packet classifier and packet scheduler reservs the requested Qos for this flow .

T Checks user authentification T Will play an important role for charging

6 IntServ (cont)

T Communicates with RSVP to create and

maintain flow-specific states in the endpoint hosts and in routers along the path of a flow

T RSVP/Intserv are complementary T Not suitable for high volume traffic

(speech)

Differentiated services

T IETF working group (draft, no RFC) T Simplify scheduling and classification using the priority bits in the IP header. T Packet flow must be marked according to SLA; Servive Level Agreements at the edge of the network T The ISP must assures that a user gets his requsted QoS. T Improves scalability greatly.

Mechanisms needed

T Setting bits in DS at the network edges

and administrative boundaries

T Using those bits to determine how packets

are treated by routers inside the network

T DS architecture is currently asymmetric;

S on-going research for symmetric architecture

Diffserv architecture

T Static and long-term

S Not need to set up QoS reservation for specific data packets S DS routing example (it is not that easy)

T Handle aggregate traffic (not per-

conversation)

S require significantly less sates and processing power than per-conversation.

RSVP - reservation protocol

T Internet control protocol - not routing protocol T Runs on top of IP and UDP T Key concepts: flows and reservations T Applies for a specific flow of data packets on a specific path. Each flow has a flow descritpor. T Both unicast and multicast . T Doesn’t understand the content of the flow descriptor

RSVP - reservation protocol

T Simplex protocol; reservation is done in

• ne direction;

T Receiver-initiated. The sender sends QoS

wanted to the receiver which sends an RSVP message back to the sender.

T The sender does not need to know the

capabilities along the path or at the receiver

7 RSVP - reservation protocol

T The RVSP daemon

S checks admission and policy control. If either fails the RSVP returns error S sets parameters in the packet classifier and packet scheduler S communicates with the routing process to determine path

Reservation messages PATH and RESV;

T PATH messages are periodically from the sender to the receiver and contains a flow spec S data format, source address, source port S traffic characteristics T RECV is generated by the receiver and contains flow spec and filter spec S follows the exact reverse path setting up reservations for one or or more senders at each node

Intserv draw backs

T Only implemented for UNIX platforms T Must be implemented on each node from

’end’-end’ - not scalable

T No secure policy mechanisms T Protecting multimedia - most traffic still

are non-multimedia

T Close to death, September 1997

RSVP renaissance today

T Availability of RSVP signaling on a large

number of hosts (Windows 2000)

T Use Diffserv as well. T Availability of policy components and

products from many vendors.

T Recent work on RSVP signalling handle

non-multimedia much better

Top-dow n provisioning

T Low overhead and aggregate traffic handling. Bilateral agreements T Difficulty learning the classification criteria that should be configured to specify specific traffic T Cannot offer high-quality guarantees required for multimedia applications, unless the network is overdimensioned T Top-down provisioning to coordinate traffic handling along a specific path

Youram Bernet

The combination of RSVP signaling with aggregate traffic handling mechanisms is able to address the deficiencies of the exclusively top-down provisioned approach without incurring the scalability problems

• f classical RSVP/intserv usage

8 Enhancing efficiency w ithin diffserv Netw ork

T Diffserv provider may dedicate resources

support SLA

T Statistical multiplexing T Dynamic signalling at certain key points;

S dynamic admission control

Yoram Bernet

When managing a network to offer QoS, the manager is faced with certain trade-offs. A given network and its QoS mechanisms can

• ffer a certain quality of guarantees at a certain

level of efficiency.

Quality/efficiency

T Trade-off; An on-going debate

S Over-provision the network;Efficiency decreases S Lower the resourses;Decrease QoS.

T It is impossible to aviod the overhead of

more sophisticated QoS mechanisms unless on is willing to compromise in the trade-off just mentioned

Yoram Bernet , QoS expert Microsoft

Despite the astounding rate at which netork capacity is increasing, we find ourselves contending with congested networks today and can expect to do be doing so for the foreseeable future

Why IP telephony (VoIP)

T Regarded far too unreliable for mass market, but now reliability and quality have quickly improved T Advantages: Cheaper

S No inter-connect charges; 6-8 kb/ s (packet) vs 64kb/ s S Regulation costs

T New value

• added features; conferencing

T Single network

Internet telephony standards

T Still immature; latency major issue T ITU-T: H.323 (set of protocols) T SIP used to initate a session between

• users. Simple, cheap. Limited, but popular

9 History of H.323

T May 1995 - H.323 work started T June 1996 - Decided by ITU-T T January 1998 - Version 2 planned for

ITU-T approval (added functions)

S ITU is learning to work on “Internet time”

H.323 Standard architectures

T Protocol stack

S Audio, video over RTP/RTCP/UDP S Data over TCP S System Control over TCP

H.323 Protocol Stack

H.225.0 H.245 G.7xx H.26x RTP RTCP Gate- keeper Reg, Adm, Status (RAS) Control Data Audio Video A/V Cntl Control TCP UDP IP T.120

H.323 Architecture

T Components

S Gateway S Gatekeeper S MCU

T Interwork with SS7

H.323 Protocol Components

T H.323 - System Document T H.225.0 - Call Signaling, Packetization S Gatekeeper Registration, Admission, and Status T H.245 - Control (also used in H.324, H.310) T T.120 - Data and Conference Control T RTP - Real-time Transport Protocol (I ETF) T RTCP - Real- time Transport Control Protocol (I ETF)

54

H.323 Gatekeeper

T Address Translation

S H.323 Alias to transport (IP) address based

• n terminal registration

S “email-like” names possible S “phone number like” names possible

T Admission control

S Permission to complete call S Can apply bandwidth limits S Method to control LAN traffic

10

55

Gatekeeper Functions (cont.)

T Management of gateway

S H.320, H.324, POTS, etc.

T Call Signaling

S May route calls in order to provide supplementary services or to provide Multipoint Controller functionality

T Call Management/Reporting/Logging

56

H.323 Terminal

T Two Versions

S Corporate Network (high quality) S Internet (optimized for low bandwidth 28.8/33.6 - G.723.1 and H.263)

T Built in Multipoint capability for Ad Hoc

conferences

T Multicast (multi-unicast) allows 3-4 people

in call without centralized mixing or switching

57

H.323 Terminal

T Two Versions

S Corporate Network (high quality) S Internet (optimized for low bandwidth 28.8/33.6 - G.723.1 and H.263)

T Built in Multipoint capability for Ad Hoc

conferences

T Multicast (multi-unicast) allows 3-4 people

in call without centralized mixing or switching

58

H.323 Gatew ays

T Provide world wide connectivity and

interoperability from LAN

S H.320, H.324, regular POTS telephones

T Map Call Signaling (Q.931 to H.225.0) T Map Control (H.242/H.243 to H.245) T Media Mapping (FEC, multiplex, rate

matching, audio transcoding, T.123 translation)

59

Multipoint : MC+MP

T MC - Multipoint Controller portion of a

traditional MCU

S Manage common modes, capabilities

T MP - Multipoint Processor

S Portion of traditional MCU mixing or switching

• audio. Not necessarily co-resident with MC.

(e.g. MC running multicast conference with each terminal mixing audio)

60

Call Setup

A Call Setup Example

T a point to point call T 3rd terminal invited into call (Ad hoc

multipoint)

T One Gatekeeper using the Direct Call

Model

11

61

Call Initiation

PictureTel

(1) ARQ Can I call “Bob”? (2a) GK resolves “Bob” to IP address through H.323 registration or external name service (e.g. DNS, ULS, etc..) (2b) Admission Policy Applied (3) ACF Yes, use this IP Address Bill Bob GK

62

Call Connection

PictureTel

(4) SETUP (Create) Bill Bob GK (5) ARQ May I answer? (6) ACF Yes (7) ALERTING (8) CONNECT (User answers)

63

H.245 Connection

PictureTel

Bill Bob (9) H.245 connection established

• Capability Exchange
• Master/Slave Determination
• Open Logical

Channels

• audio, video

For this example, assume Bill wins the Master/Slave determination and becomes the Multipoint Controller (MC) of the conference

64

Bill invites Ross

PictureTel

Ross GK (10) ARQ Invite Ross (11) ACF Resolved Ross’s IP Address (12) SETUP (Invite) (13) ARQ May I Join? (14) ACF Yes (15) ALERTING (16) CONNECT (17) H.245 CONNECTION

65

Work in progress

T H.323

S Implementors Guide S Version 2 S Supplementary Services

T H.225.0

S Version 2 S Annex E - Video Packetization (w/IETF) S Annex F - Audio Packetization (w/IETF)

66

H.323/H.225.0 Version 2

T Enhanced procedural descriptions T Gateway registration and selection

procedures, registration capabilities

T Authentication and Security T MC

Cascading and transfer of MC

T Relationship to T.120 and T.130 T RAS Retry/Time-out T Additional audio and video packetizations

12 Signalling w ithin H.323

T H.323 uses a logicla channel on the LAN T RAS (Registration, admission and status)

S Gatekeeper Discovery S Endpoint registration S Call management S Admission procedures S and several more

VoIPoW (over w ireless (wcdma))

T Rather important reserach in Ericsson T Challenge cube