IP Telephony and Multimedia transport protocols

1
IP Telephony and Multimedia transport protocols

• Xiaowei Yang

2
Administrative Trivia

• Hw 2 due
• Email me to set up an appointment if you cannot
  make the regular office hours
• Mid-term evaluation
• Its active! We can still adjust the rest of the
  lectures
• Tell me too fast/slow, too much/little work,
  what you feel interesting/uninteresting etc.
• Anything that might improve the remaining
  lectures
• Schedule adjustment
• RPC and RPC-based applications before social
  networks

3
Outline of Todays Lecture

• Open protocols that support IP telephony and
  other multi-media applications
• Weve discussed Skype
• Highlight the difference between an
  application-oriented approach and a
  standard-driven approach
• Design principle requirements-driven design
• Requirements of multimedia applications
• Video conferencing, telephony, real-time
  streaming, VoD
• Protocols
• SIP, ENUM
• RTP, RTCP
• DiffServ, RSVP

4
Multimedia data Digital Audio

• Sampling the analog signal
• Sample at some fixed rate
• Each sample is an arbitrary real number
• Quantizing each sample
• Round each sample to one of a finite number of
  values
• Represent each sample in a fixed number of bits

4 bit representation(values 0-15)
5
Audio Examples

• Speech
• Sampling rate 8000 samples/second
• Sample size 8 bits per sample
• Rate 64 kbps

• Compact Disc (CD)
• Sampling rate 44,100 samples/second
• Sample size 16 bits per sample
• Rate 705.6 kbps for mono, 1.411 Mbps
  for stereo

6
Audio Compression

• Audio data requires too much bandwidth
• Speech 64 kbps is too high for a dial-up modem
  user
• Stereo music 1.411 Mbps exceeds most access
  rates
• Compression to reduce the size
• Remove redundancy
• Remove details that human tend not to perceive
• Example audio formats
• Speech GSM (13 kbps), G.729 (8 kbps), and
  G.723.3 (6.4 and 5.3 kbps)
• Stereo music MPEG 1 layer 3 (MP3) at 96 kbps,
  128 kbps, and 160 kbps

7
Multimedia data Digital Video

• Sampling the analog signal
• Sample at some fixed rate (e.g., 24 or 30 times
  per sec)
• Each sample is an image
• Quantizing each sample
• Representing an image as an array of picture
  elements
• Each pixel is a mixture of colors (red, green,
  and blue)
• E.g., 24 bits, with 8 bits per color

8
The 320 x 240hand
The 2272 x 1704hand
9
Video Compression Within an Image

• Image compression
• Exploit spatial redundancy (e.g., regions of same
  color)
• Exploit aspects humans tend not to notice
• Common image compression formats
• Joint Pictures Expert Group (JPEG)
• Graphical Interchange Format (GIF)

Uncompressed 167 KB
Good quality 46 KB
Poor quality 9 KB
10
Video Compression Across Images

• Compression across images
• Exploit temporal redundancy across images
• Common video compression formats
• MPEG 1 CD-ROM quality video (1.5 Mbps)
• MPEG 2 high-quality DVD video (3-6 Mbps)
• Proprietary protocols like QuickTime and
  RealNetworks

11
Case study telephone

• Requirements

12
Case study real time streaming
13
Case study video conferencing
14
Requirements for Data Transport

• Delay
• Some small delay at the beginning is acceptable
• E.g., start-up delays of a few seconds are okay
• Jitter
• Variability of packet delay within the same
  packet stream
• Client cannot tolerate high variation if the
  buffer starves
• Loss
• Small amount of missing data does not disrupt
  playback
• Retransmitting a lost packet might take too long
  anyway

15
Requirements drive the design of general purpose
protocols

• Real-time transport protocol
• Session control protocols
• Session description protocol
• Session announcement protocol
• Session initiation protocol
• Simple conference control protocol
• Resource reservation protocol
• DiffServ architecture
• Packet marking, policing

16
TCP is Not a Good Fit

• Reliable delivery
• Retransmission of lost packets
• even though it may not be useful
• Adapting the sending rate
• Slowing down after a packet loss
• even though it may cause starvation at the
  client
• Protocol overhead
• TCP header of 20 bytes in every packet
• which is large for sending audio samples
• Sending ACKs for every other packet
• which may be more feedback than needed

17
Recovering From Packet Loss

• Loss is defined in a broader sense
• Does a packet arrive in time for playback?
• A packet that arrives late is as good as lost
• Retransmission is not useful if the deadline has
  passed
• Selective retransmission
• Sometimes retransmission is acceptable
• E.g., if the client has not already started
  playing the data
• Data can be retransmitted within the time
  constraint

18
RTP

• Run on top of UDP
• Skype also uses UDP
• What are the advantages and disadvantages of
  specifying a protocol?

19

• Much of RTP derived from an early conference
  application vat.

20
RTP high-level functions

• Allows similar applications to interoperate
• Communicate the choice of coding scheme
• Determine timing relationship (in the next two
  slides)
• Synchronization of multiple media streams
• Audio, video
• Indication of packet loss
• Why is it useful?
• Frame boundary indication
• User-friendly sender identification

21
Playback Buffer

• Client buffer
• Store the data as it arrives from the server
• Play data for the user in a continuous fashion
• Playback delay
• Client typically waits a few seconds to start
  playing
• to allow some data to build up in the buffer
• to help tolerate some delays down the road

22
Influence of Playback Delay
23
RTP high-level design

• RTP defines a pair of protocol RTP and RTCP
• RTCP sends periodic control information
• Use consecutive port numbers
• RTP defines a profile and one or more formats
• Data format Audio sample, or MPEG encoding
  frames
• Application-layer framing
• Application understands best its need

24
RTP Header

• First 12 bytes are always present
• Format of payload is determined by applications
• No length field!
• V version P padding X extension header
  (rarely used. Why?) CC number of contributing
  sources M marker bit PT payload type that
  describes encoding scheme
• Timestamp enable playback, specified in terms of
  ticks
• Clock granularity is specified in a RTP profile
• SSRC sender ID.
• CSRC when a number of sources are mixed together

25
Examples of Timestamp

• If the sample interval is 125us, and the nth
  packet has a timestamp 0, and the first sample in
  the n1th packet is generated 10 ms later, whats
  the timestamp in the n1 th packet?

26
RTCP

• Demonstrates the flexibility of designing
  transport protocols
• It provides three main functions
• Feedback on the performance of the application
  and the network
• Useful for rate-adaptive applications
• A way to correlate and synchronize different
  media streams that have come from the same sender
• Note different media streams are often sent by
  different RTP sessions
• A way to convey the identity of a sender for
  display

27
Correlating senders

• A sender may have multiple SSRC values
• Multiple streams from the same node
• SSRC collisions
• A CNAME is assigned to a sender
• Various SSRCs of the sender are associated with
  the CNAME

28
RTCP packet types

• Sender reports enable active senders to a
  session to report transmission and reception
  statistics
• Receiver reports receivers that are not senders
  use to report reception statistics
• Source descriptions carry CNAMEs and other
  sender information
• Application-specific control packets

29
RTCP packets

• At least two RTCP packets are sent in every
  lower-level protocol data unit (a UDP packet)
• A report packet
• A source description packet
• Scalability
• Scale back report frequency as the number of
  participants increases

30
Sender report extra information

• A timestamp that contains the time of day when a
  report is generated
• A RTP timestamp
• The two enable cross-stream synchronization
• Cumulative number of packets and bytes sent by
  this sender since it begins

31
Sender and receiver report common information

• One block of data per source
• Its SSRC
• Fraction of lost data
• How?
• Total lost packets
• Highest sequence number
• Estimated jitter
• How?
• Last actual timestamp received via RTCP for this
  source
• Delay since last sender report received via RTCP
  for this source

32
What can a recipient learn?

• Other recipients quality of service
• Whether a sender should adjust coding scheme

33
Source description packet

• SSRC of the sender and the senders CNAME
• All applications that may require synchronization
  choose the same CNAME
• username_at_host
• xwy_at_spirit.ics.uci.edu

34
Session control protocols

• Session description protocol
• Session announcement protocol
• Session initiation protocol
• Simple conference control protocol

35
Session description protocol

• Name and purpose of the session
• Start and end times
• Media type
• Detailed information to receive the session, e.g,
  the multicast address, the transport protocol,
  port numbers, and encoding schemes

36
SDP cont.

• ASCII-based protocol as other protocols we
  learned before

v0 ojdoe 2890844526 2890842807 IN IP4
10.47.16.5 sSDP Seminar iA Seminar on the
session description protocol uhttp//www.example
.com/seminars/sdp.pdf ej.doe_at_example.com (Jane
Doe) cIN IP4 224.2.17.12/127 t2873397496
2873404696 arecvonly maudio 49170 RTP/AVP 0
mvideo 51372 RTP/AVP 99 artpmap99
h263-1998/90000
37
Session initiaion protocol

• User location determining the correct device to
  which to communicate to reach a particular user
• User availability determining if the user is
  willing to take part in a particular
  communication session
• User capabilities determining such items such as
  the choice of media and coding scheme to use
• Session setup establishing session parameters
  such as port numbers to be used by the
  communicating parties
• Session management a range of functions
  including transferring sessions and modifying
  session parameters

38
VoIP Gateways
Corporate/Campus
Another campus
7040
8151
External line
8152
7041
PBX
PBX
8153
VoIP Gateway
8154
7042
VoIP Gateway
7043
Internet
LAN
LAN
IP Phone Client
39
Proxy-based architecture

• A proxy is a point of contact

40
Message flow for a basic SIP session
41
Invite message details
INVITE sipbob_at_biloxi.com SIP/2.0 Via
SIP/2.0/UDP pc33.atlanta.combranchz9hG4bK776asdh
ds Max-Forwards 70 To Bob
From Alice tag19283017
74 Call-ID a84b4c76e66710_at_pc33.atlanta.com
CSeq 314159 INVITE Contact anta.com Content-Type application/sdp
Content-Length 142
42
Other SIP features

• Users register with SIP registrar
• Proxy may fork parallel connections

43
Enum

• Typical use case caller is in PSTN (can use only
  digit keys) and would like to reach a SIP callee
  (if not for other reasons, then because PSTN
  routing is too costly)
• Answer ENUM. Create a global directory with
  telephone numbers that map to SIP addresses (or
  e-mail, etc.).

44
ENUM Translation andOwnership

• The ENUM global directory translates E.164
  numbers into URIs, e.g. 49-30-3463-8271
  jiri_at_iptel.org
• The translation mechanism utilizes DNS The E.164
  number queries are formed as a reversed
  dot-separated number digits, to which string
  .e164.arpa is appended, e.g.
• 4319793321 1.2.3.3.9.7.9.1.3.4.e164.arpa
• Operation of the top-level domain carried out by
  RIPE-NCC http//www.ripe.net/enum/
• Responsibility for respective countries in the
  ENUM DNS tree is frequently claimed by local NICs
  (nic.at, nic.cz, ) or specialized ENUM
  companies (Neustar, Verisign, ). Delegation
  still subject to disputes in many countries
  number ownership verification is matter of local
  policies.

45
ENUM Call Flow
46
Principles for QoS Guarantees

• Applications compete for bandwidth
• Consider a 1 Mbps VoIP application and an FTP
  transfer sharing a single 1.5 Mbps link
• Bursts of FTP traffic can cause congestion and
  losses
• We want to give priority to the audio packets
  over FTP
• Principle 1 Packet marking
• Marking of packets is needed for the router
• To distinguish between different classes

47
Principles for QoS Guarantees

• Applications misbehave
• Audio sends packets at a rate higher than 1 Mbps
• Principle 2 Policing
• Provide protection for one class from other
  classes
• Ensure sources adhere to bandwidth restrictions
• Marking and policing need to be done at the edge

48
Principles for QoS Guarantees

• Alternative to marking and policing
• Allocate fixed bandwidth to each application flow
• But, this can lead to inefficient use of
  bandwidth
• if one of the flows does not use its allocation
• Principle 3 Link scheduling
• While providing isolation, it is desirable to use
  resources as efficiently as possible
• E.g., weighted fair queuing or round-robin
  scheduling

49
Principles for QoS Guarantees

• Cannot support traffic beyond link capacity
• If total traffic exceeds capacity, you are out of
  luck
• Degrade the service for all, or deny someone
  access
• Principle 4 Admission control
• Application flow declares its needs in advance
• The network may block call if it cannot satisfy
  the needs

50
Resource allocation
51
Conclusions

• Application-driven protocol design
• RTP/RTCP
• SIP
• Skype versus SIP
• Discussion