Schedule of Class Meeng

Mul$media  Networking  

  

#5  Real-­‐Time  Transport  Protocol  

Semester  Ganjil  2012  

PTIIK  Universitas  Brawijaya   Schedule  of  Class  Mee$ng   1.

    Introduc$on     2.

    Applica$ons  of  MN   3.

    Requirements  of  MN   4.

    Coding  and   Compression  

  5.   RTP  

  6.  IP  Mul$cast  

  7.  IP  Mul$cast  (cont’d)    

  8.  Overlay  Mul$cast  

  9.  CDN:  Solu$ons  

  10. CDN:  Case  Studies  

  11. QoS  on  the  Internet:   Constraints  

  12. QoS  on  the  Internet:   Solu$ons  

  13. Discussion   14.

   Summary   Today’s  Outline  

• RTP  
• –  protocol  goals  
• –  mixers  and  translators  
• –  control:  awareness,  QOS  feedback    
• –  media  adapta$on    

    RTP:  Big  Picture   Media   Encapsula$on  

  Real-­‐Time  Protocol  (RTP)  

• RTP  encapsula$on  only   seen  at  end  systems   ( not  by  intermediate   routers)  
>End-­‐to-­‐end  protocol   for  applica$ons   transmi_ng  real-­‐$me   data,  such  as  audio   and  video  
• RFC  3550  
• RTP  packets   encapsulated  in  UDP   segments &n
  • –  routers  provide  best-­‐ effort  service,  no   special  effort  to   ensure  RTP  packets   arrive  at  des$na$on   in  $mely  manner

  RTP   RTCP   Applica$on  

  UDP  

  IPv4/6   Ethernet   AAL5   ATM  

  ST-­‐II   data   control   RTP:  Big  Picture  

• Real-­‐Time  Transport  Protocol  (RTP)  =  data  +   control    
• data:    
• –  $ming,    
• –  loss  detec$on,    
• –  content  labeling,    
• –  talk  spurts,    
• –  encryp$on    

• •  control:  (RTCP)    periodic  with  T  ∼popula$on    

• –  QOS  feedback    
• –  membership  es$ma$on  
• –  loop  detec$on    

RTP:  Goals  

• lightweight:  specifica$on  and  implementa$on    
• flexible:  provide  mechanism,  don’t  dictate   algorithms    

• •  protocol-­‐neutral:  UDP/IP,ST-­‐II,IPX,ATM-­‐AALx,...    

• scalable:  unicast,  mul$cast  from  2  to  O(107)    
• separate  control/data:  some  func$ons  may  be   taken  over  by  conference  control  protocol    
• secure:  support  for  encryp$on,  possibly   authen$ca$on    

RTP  runs  on  top  of  UDP  

• Applica$on  layer  protocol  

• •  RTP  libraries  provide  transport-­‐layer  interface  

  that  extends  UDP:   &n> port  numbers,  IP  addresses  
•  payload  type  iden$fica$on  
•  packet  sequence  numbering  
•  $me-­‐stamping &n>Applica$ons  that  use  RTP  are:  
• Less  sensi$ve  to  packet  loss  
• Very  sensi$ve  to  packet  delays &n>UDP  provides  key  services:  
• Mul$plexing    
• Checksum    

RTP  Func$ons  

• segmenta$on/reassembly  done  by  UDP  (or  similar)  
• re-­‐sequencing  (if  needed)  
• loss  detec$on  for  quality  es$ma$on,  recovery  
• intra-­‐media  synchroniza$on:  remove  delay  jiker   through  playout  buffer  

• •  intra-­‐media  synchroniza$on:  driling  sampling  clocks    

• •  inter-­‐media  synchroniza$on  (lip  sync  between  audio  

  and  video)  
• quality-­‐of-­‐service  feedback  and  rate  adapta$on  
• source  iden$fica$on    

RTP  header  

  bit

  8

  16

  24

  32 CSRC V(2) P

  X M payload type sequence number count

  timestamp synchronization source identifier (SSRC)

  contributing source identifiers (CSRC) opt.

  UDP packet header extension opt. payload (audio,video,...)

  0x00 opt.

  bytes

  

RTP  header  

payload sequence Synchronization Miscellaneous time stamp type number type Source ID fields

payload  type  (7  bits):   audio/video  encoding  method;  may  change  

  during  session.  If  sender  changes  encoding  during  call,  sender     informs  receiver  via    payload  type  field  

  Payload  type  0:  PCM  mu-­‐law,  64  kbps   Payload  type  3:  GSM,  13  kbps   Payload  type  7:  LPC,  2.4  kbps   Payload  type  26:  Mo$on  JPEG   Payload  type  31:  H.261   Payload  type  33:  MPEG2  video     sequence  #  (16  bits):   +1  for  each  RTP  packet  sent  

  detect  packet  loss,  restore  packet  sequence  

    

  

RTP  header  

payload sequence Synchronization Miscellaneous time stamp type number type Source ID fields

• sampling  instant  of  
• *mestamp  field  (32  bits  long):  

  first  byte  in  this  RTP  data  packet  

• –  for  audio,  $mestamp  clock  increments  by  one  for  each   sampling  period  (e.g.,  each  125  usecs  for  8  KHz  sampling   clock)    
• –  if  applica$on  generates  chunks  of  160  encoded  samples,  

  $mestamp  increases  by  160  for  each  RTP  packet  when   source  is  ac$ve.  Timestamp  clock  con$nues  to  increase   at  constant  rate  when  source  is  inac$ve.  

•  

       synchroniza$on  source

    SSRC  field  (32  bits  long):

• –  sources  pick  at  random  ➠  may  change  aler  collision!  

   

  Source ID Miscellaneous fields

  padding  (for  encryp$on)  ➠  last  byte  has   padding  count  

• P:  

  marker  bit;  frame,  start  of  talk  spurt  ➠   delay  adjustment    

• M:  

  

content  source  count  (for  mixers)  

• CC:  

  iden$fiers  of  those  contribu$ng  to   (mixed  into)  packet     RTP  header   payload type sequence number type time stamp Synchronization

• CSRC:  

  RTP  example   example:   sending  64  kbps   PCM-­‐encoded  voice  over   RTP  

• RTP  header  indicates   type  of  audio   encoding  in  each   packet  
>applica$on  collects   encoded  data  in  chunks,   e.g.,  every  20  msec  =   160  bytes  in  a  chunk  
• audio  chunk  +  RTP   header  form  RTP  packet,   which  is  encapsulated  in   UDP  segment   &n
  • –  sender  can  change   encoding  during   conference    

• RTP  header  also   contains  sequence   numbers,  $mestamps  

Today’s  Outline  

• RTP  
• – mixers  and  translators  

    protocol  goals  

• – –  control:  awareness,  QOS  feedback    

   

• –  media  adapta$on    

  

RTP:  Mixers  and  Translators  

• mixer:    
• –  several  media  stream  ➠  one  new  stream  (new  encoding)    
• –  reduced  bandwidth  networks  (dial-­‐up)    
• –  appears  as  new  source,  with  own  iden$fier    
• –  single  media  stream  

    translator:    

• –  may  convert  encoding  
• –  protocol  transla$on  (na$ve  ATM  ↔  IP),  firewall  
• –  all  packets:  source  address  =  translator  address    
• Goals:  Accommodate  par$cipant  network  resources  

  RTP:  Mixers  and  Translators   SSRC=39 SSRC=17

  192.35.149.52 128.119.40.186 192.26.8.84 192.20.225.101

  SSRC=5 DVI4 L16 GSM GSM

  SSRC=5 translator end system end system mixer

  CSRC=

  17

  39 Today’s  Outline  

• RTP  
• –   mixers  and  translators  

    protocol  goals  

• – control:  awareness,  QOS  feedback  
• –    

   

• –  media  adapta$on

  

Control:  awareness,  QOS  feedback  

• Packet  loss,  conges$on,  jiker,  delivery  $mes  
• –  Directly  useful  for  control  of  adap$ve  encodings  
• –  Iden$fy  if  problems  are  local  or  global  
• –  Short-­‐term  and  long-­‐term  sta$s$cal  analysis    
• Self-­‐adjus$ng  network    
• –  Each  par$cipant  eventually  knows  about  the  other   members  
• –  Source  descrip$on  dynamically  iden$fies  who  is  sending  
• –  Ac$ve  senders  get  more  bandwidth    
• –  Session  bandwidth  kept  constant  by  adjus$ng   transmission  rate  based  on  the  number  of  par$cipants  
Real-­‐Time  Control  Protocol  (RTCP)  

• each  RTCP  packet   contains  sender  and/or   receiver  reports  
>works  in  conjunc$on   with  RTP  
• each  par$cipant  in  RTP   session  periodically   sends  RTCP  control   packets  to  all  other   par$cipants &n
  • –  report  sta$s$cs  useful  to     applica$on:  #  packets   sent,  #  packets  lost,   interarrival  jiker  

• feedback  used  to  control   performance  
• –  sender  may  modify  its   transmissions  based  on     feedback  
RTCP:  packet  types  

• stackable  packets,  similar  to  data  packets  
• sender  report  (SR):    
• –  bytes  send  ➠  es$mate  rate;  
• –  $mestamp  ➠  synchroniza$on  
• recep0on  reports  (RR):    
• –  number  of  packets  sent  and  expected  ➠  loss,  avg.  inter-­‐ arrival  jiker,  round-­‐trip  delay    
• source  descrip0on(SDES):    
• –  name,  email,  loca$on,...    
• –  CNAME  (canonical  name  =  user@host)  iden$fies  user   across  media    

  in  addi$on  to  $me-­‐out  

• explicit  leave  (BYE):  

  applica$on-­‐specific  (none  yet)    

• extensions  (APP):  

RTCP:  packet  structure  

  if encrypted: random 32-bit integer packet packet packet _{sender site 1 site 2 receiver reports item item item item CNAME PHONE CNAME LOC reason} chunk chunk SR _{SSRC SSRC SSRC SSRC SSRC SSRC SSRC report} SDES

  BYE

compound packet

UDP packet RTCP:  mul$ple  mul$cast  senders   

   

  each  RTP  session:  typically  a  single  mul$cast  address;    

    

  every  par$cipant:  periodically  mul$cast  RTCP  packet  to  same   group  as  data    

    

  RTP,  RTCP  packets  dis$nguished  from  each  other  via  dis$nct  port   numbers  

    

  to  limit  traffic,  each  par$cipant  reduces  RTCP  traffic  as  number  of   conference  par$cipants  increases     ^{RTCP RTP RTCP RTCP}

  sender receivers RTCP:  announcement  interval  

• Goals:  
• –  es$mate  current  number  of  par$cipants  &  iden$$es   of  par$cipants  –  dynamic  
• –  source  descrip$on  (“SDES”)  ➠  who’s  talking?  

• –  quality-­‐of-­‐service  feedback  ➠  adjust  sender  rate  

• –  to  O(1000)  par$cipants,  few  %  of  data    
• ➠  randomized  response  with  rate  ↓  as  members  ↑  
• –  group  size  limited  by  tolerable  age  of  status  
• –  gives  ac$ve  senders  more  bandwidth  
• –  sol  state:  delete  if  silent    

  RTCP:  bandwidth  scaling   RTCP  aAempts  to  limit   its  traffic  to  5%  of   session  bandwidth     example  :   one  sender,  

• –  with  R  receivers,    each  receiver   gets  to  send  RTCP  traffic  at  75/ R  kbps.    
• sender  gets  to  send  RTCP   traffic  at  25  kbps.

  sending  video  at  2  Mbps  

     

• par$cipant  determines  RTCP   packet  transmission  period   by  calcula$ng  avg  RTCP   packet  size  (across  en$re   session)  and  dividing  by     allocated  rate    
• RTCP  akempts  to  limit  

  RTCP  traffic  to  100  Kbps  

• RTCP  gives  75%  of    rate  to   receivers;  remaining  25%   to  sender  
• 75  kbps  is  equally  shared   among  receivers:    

  

RTCP:  bandwidth  scaling  

• sender period T : # of senders · avg. RTCP packet size T = .25 · 0.05 · session bw
• receivers: # of receivers T =

  · avg. RTCP packet size .75 · 0.05 · session bw

• next packet = last packet + max(5 s, T ) · random(0.5. . . 1.5)
• randomization prevents “bunching”
• to reduce RTCP bandwidth, alternate between SDES components

  

RTCP  sender  reports  (SR)  

• iden$fies  source  of  data  

    SSRC  of  sender:   when  report  was  sent  

• corresponding  “RTP  $me”  ➠  

    NTP  *mestamp:  

• RTP  *mestamp:  

  lip  sync     total  number  sent     sender’s  packet  count:  

• total  number  sent  
• followed  by  zero  or  more  receiver  report      

    sender’s  octet  count:   iden$fies  who’s  being  reported  on  

  

RTCP  receiver  reports  (RR)  

• SSRC  of  source:  

  binary  frac$on  

• frac*on  lost:  

  long-­‐term  loss  

• cumula*ve  number  of  packets  lost:  

  :  compare  losses,   disconnect    

• highest  sequence  number  received

    smoothed  inter-­‐packet  distor$on    

• inter-­‐arrival  jiAer:

   $me  last  SR  heard    

• LSR:

  delay  since  last  SR    

• DLSR:  

  

RTCP:  round  trip  delay  es$ma$on  

• compute  round-­‐trip  delay  between  data   sender  and  receiver  

  [10 Nov 2001 11:33:25.125] [10 Nov 2001 11:33:36.5] SR(n) n A=0xb710:8000 (46864.500 s) ntp_sec =0xb44db705 dlsr=0x0005.4000 ( 5.250 s) ntp_frac=0x20000000 lsr =0xb705:2000 (46853.125 s) (3024992016.125 s)

  RR(n) r DLSR (5.25 s)

  A 0xb710:8000 (46864.500 s) DLSR −0x0005:4000 ( 5.250 s) LSR −0xb705:2000 (46853.125 s) delay 0x 6:2000 ( 6.125 s)

RTCP:  stream  synchroniza$on  

• RTCP  can  synchronize  
• each  RTCP  sender-­‐report   different  media  streams   packet  contains  (for  most   within  a  RTP  session     recently  generated  packet &n
• e.g.,  videoconferencing  app:   in  associated  RTP  stream):   each  sender  generates  one  
• –  $mestamp  of  RTP  packet     RTP  stream  for  video,  one   for  audio.    
• –  wall-­‐clock  $me  for  when   packet  was  created  
• $mestamps  in  RTP  packets  

  $ed  to  the  video,  audio  

• receivers  uses  associa$on   sampling  clocks   to  synchronize  playout  of   audio,  video    
• –  not  $ed  to  wall-­‐clock  

  $me   RTCP:  stream  synchroniza$on   =  sync  different  streams  (audio,  video,   slides,  .  .  .  )    

• –  $mestamps  are  offset  with  random  intervals    
• –  may  not  $ck  at  nominal  rate  
• –  SRs  correlate  “real”  $me  (wall  clock  $me)  with   RTP  ts    

  560 = 8:45:17.23 audio 160 320 480 640 800 960 1120

  RTCP SR RTP RTP timestamp

  1800 = 8:45:17.18 video

  9000 Today’s  Outline  

• RTP  
• –   protocol  goals  
• –   mixers  and  translators  
• –   control:  awareness,  QOS  feedback  
• –   media  adapta$on    

  Media  Adapta$on  

• •  Mul$media  applica$ons  can  adjust  their  data  rates:  

• Audio:  (MPEG  L3),  encoding,  sampling  rate,  mono/ stereo    

  encoding sampling rate bit rate LPC 8,000 5,600 GSM 8,000 13,200 DVI4 8,000 32,000 µ

• law 8,000 64,000 DVI4 16,000 64,000 a range of DVI4 and MPEG L3 L16 stereo 44,100 1,411,200

Media  Adapta$on  

• Video:  frame  rate,  quan$za$on,  image  resolu$on,  encoding    

  30000 Noise

  Face 1 25000

  Face 2 White Picture

  Black Picture 20000 15000

  Size [Bytes] 10000 5000

  50 100 150 200 250 300 Q-Factor

  

Applica$on  Control  

• •  networks  without  QoS  or  shared  reserved  link:  

• –  adapt  applica$on  to  available  bandwidth  
• –  share  bandwidth  fairly  with  TCP?  
• –  lowest  common  denominator  
• mixers,  translators    

  

RTP/RTCP   Does  NOT  

• Define  media  data  formats  or  encodings    
• –  Need  media  specific  profiles  
• Handle  connec$on  setups  
• –  Need  other  protocols  like  SIP  or  H.323  
• Handle  resource  reserva$on    
• –  Need  other  protocols  like  RSVP    
• Guarantee  $mely  data  delivery  or  Quality  of   Service  
• –  However,  it  does  provide  necessary  data  to   applica$on  to  order  packets  and  adjust  signal  quality    

  

References

• RFC  3550  -­‐  hkp://tools.ie{.org/html/rfc1889    
• RFC  3551  -­‐  hkp://tools.ie{.org/html/rfc3551    
• Wikipedia:    

• –  RTP  -­‐  hkp://en.wikipedia.org/wiki/Real-­‐$me_Transport_Protocol    

• –  RTCP  -­‐  hkp://en.wikipedia.org/wiki/RTCP