SLIDE 1
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
SLIDE 2 2 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
SLIDE 3
3 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
SLIDE 4 4 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
S Also used for synchronize different streams; audio an video in MPEG. ( Application level responsible for the actual synchronization)
SLIDE 5
5 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
SLIDE 6 6 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
control (RTCP)
T Not complete - new payload format
SLIDE 7
7 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
SLIDE 8
8 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 ….
SLIDE 9
9 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)
SLIDE 10
10 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
SLIDE 11
11 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
SLIDE 12 12 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
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
SLIDE 13
13 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
SLIDE 14 14 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
SLIDE 15 15 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
SLIDE 16 16 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
SLIDE 17
17 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
SLIDE 18 18 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
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
SLIDE 19 19
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
SLIDE 20 20
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
SLIDE 21 21
61
Call Initiation
P i c t u r e T e l P i c t u r e T e l
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
P i c t u r e T e l P i c t u r e T e l
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
P i c t u r e T e l P i c t u r e T e l
PictureTel
Bill Bob (9) H.245 connection established
- Capability Exchange
- Master/Slave Determination
- Open Logical
Channels
For this example, assume Bill wins the Master/Slave determination and becomes the Multipoint Controller (MC) of the conference
SLIDE 22 22
64
Bill invites Ross
P i c t u r e T e l P i c t u r e T e l
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
SLIDE 23
23 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
