Internet Engineering Task Force			    Audio-Video	Transport WG
INTERNET-DRAFT draft-ietf-avt-rtp-03.txt	    H. Schulzrinne/S. Casner
								    AT&T/ISI
							  September 15,	1993
							  Expires:  11/01/93


	    RTP: A Transport Protocol for Real-Time Applications



Status of this Memo


This document is an Internet Draft.   Internet Drafts are working  documents
of the Internet	Engineering  Task Force	(IETF),	its  Areas, and	its  Working
Groups.	  Note that other  groups may also  distribute working documents  as
Internet Drafts.

Internet Drafts	 are draft  documents valid  for a  maximum of	six  months.
Internet Drafts	may be	updated, replaced, or  obsoleted by other  documents
at any time.   It  is not appropriate  to use Internet	Drafts as  reference
material or to	cite them other	 than as  a ``working draft''  or ``work  in
progress.''

Please check  the I-D  abstract	 listing contained  in each  Internet  Draft
directory to learn the current status of this or any other Internet Draft.

Distribution of	this document is unlimited.


				  Abstract


     This  memorandum describes	a protocol called  RTP suitable	for the
    end-to-end	network	transport  of real-time	 data,	such  as audio,
    video or simulation	 data for both multicast  and unicast transport
    services.	The data transport  is augmented by  a control protocol
    (RTCP)  designed  to  provide minimal  control  and	 identification
    functionality particularly in multicast networks.  RTP and RTCP are
    designed to	be independent of  the underlying transport and	network
    layers.  The protocol supports the use of RTP-level	translators and
    bridges.   Within multicast	associations, sites  can direct	control
    messages  to individual  sites.    The  protocol  does not	address
    resource reservation and does  not guarantee quality-of-service for
    real-time services.


This specification is a	product	 of the	Audio-Video Transport working  group
within the Internet  Engineering Task  Force.	Comments  are solicited	 and


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

should be addressed to the  working group's mailing list at  rem-conf@es.net
and/or the authors.



Contents


1 Introduction								   3

2 RTP Protocol Use Scenarios						   5

  2.1 Simple Multicast Audio Conference	. . . .	. . . .	. . . .	. . . .	. 5

  2.2 Bridges .	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 6

  2.3 Translators . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 6

  2.4 Security	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	.  7


3 Definitions								   7

4 Byte Order, Alignment, and Reserved Values				  10


5 Real-Time Data Transfer Protocol -- RTP				  10

  5.1 RTP Fixed	Header Fields .	. . . .	. . . .	. . . .	. . . .	. . . .	. 10

  5.2 The RTP Options .	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 12

    5.2.1CSRC: Content source identifiers . . .	. . . .	. . . .	. . . .	. 13

    5.2.2SSRC: Synchronization source identifier  . . .	. . . .	. . . .	. 13

    5.2.3BOS: Beginning	of synchronization unit	. . . .	. . . .	. . . .	. 14

  5.3 Reverse-Path Option . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 14

    5.3.1SDST: Synchronization destination identifier .	. . . .	. . . .	. 15

  5.4 Security Options	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 16

    5.4.1ENC: Encryption  . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 18

    5.4.2MIC: Messsage integrity check	. . . .	. . . .	. . . .	. . . .	. 19

    5.4.3MICA: Message integrity check,	asymmetric encryption .	. . . .	. 20

    5.4.4MICK: Message integrity check,	keyed .	. . . .	. . . .	. . . .	. 21


H. Schulzrinne/S. Casner	      Expires 11/01/93		    [Page 2]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

    5.4.5MICS: Message integrity check,	symmetric-key encrypted	. . . .	. 22


6 Real Time Control Protocol --- RTCP					  22

  6.1 FMT: Format description .	. . . .	. . . .	. . . .	. . . .	. . . .	. 23

  6.2 SDES: Source descriptor .	. . . .	. . . .	. . . .	. . . .	. . . .	. 24

  6.3 BYE: Goodbye  . .	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 27

  6.4 QOS: Quality of service measurement . . .	. . . .	. . . .	. . . .	. 27

7 Security Considerations						  28


8 RTP over Network and Transport Protocols				  29

  8.1 Defaults	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 29

  8.2 ST-II . .	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 30

A Implementation Notes							  30

  A.1 Timestamp	Recovery  . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 31

  A.2 Detecting	the Beginning of a Synchronization Unit	. . . .	. . . .	. 32

  A.3 Demultiplexing and Locating the Synchronization Source  .	. . . .	. 33

  A.4 Parsing RTP Options . . .	. . . .	. . . .	. . . .	. . . .	. . . .	. 33

  A.5 Determining the Expected Number of RTP Packets  .	. . . .	. . . .	. 34


B Addresses of Authors							  35


1 Introduction


This memorandum	specifies a  transport protocol	for real-time  applications.
A discussion of	real-time services  and	algorithms for their  implementation
and some of the	 RTP design decisions  can be found  in	the current  version
of the	companion  Internet  draft draft-ietf-avt-issues.     The  transport
protocol provides  end-to-end  delivery	 services for  data  with  real-time
characteristics, for  example,	interactive audio  and video.	 RTP  itself
does not provide any  mechanism	to ensure timely  delivery or provide  other
quality-of-service guarantees, but relies on lower-layer services to do	 so.
It does	___ guarantee  delivery	or prevent  out-of-order delivery, nor	does
it assume that the  underlying network is reliable  and	delivers packets  in


H. Schulzrinne/S. Casner	      Expires 11/01/93		    [Page 3]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

sequence.   The	sequence numbers  included in  RTP allow the  end system  to
reconstruct the	sender's packet	 sequence, but	sequence numbers might	also
be used	to determine the proper	location  of a packet, for example in  video
decoding, without necessarily decoding	packets	in sequence.   RTP does	 not
provide	quality-of-service guarantees.	 RTP  is designed to  run on top  of
a variety of  network and  transport protocols,	 for example,  IP, ST-II  or
UDP.(1)	RTP  transfers data  in	a  single  direction, possibly	to  multiple
destinations if	 supported by  the  underlying network.	   A  mechanism	 for
sending	control	data in	the opposite direction,	reversing the path traversed
by regular data, is provided.

While RTP is primarily	designed to satisfy  the needs of  multi-participant
multimedia conferences,	it  is not limited  to that particular	application.
Storage	of  continuous	data,  interactive  distributed	 simulation,  active
badge,	and  control  and   measurement	 applications  may  also  find	 RTP
applicable.   Profiles are  used to  instantiate certain  header fields	 and
options	for particular sets of applications.  A	profile	for audio and  video
data may be found in the companion Internet draft draft-ietf-avt-profile.

The current  Internet  does not	 support  the widespread  use  of  real-time
services.     High-bandwidth  services	using	RTP,  such  as	video,	 can
potentially seriously degrade other  network services.	 Thus,	implementors
should take  appropriate precautions  to limit	accidental bandwidth  usage.
Application  documentation  should  clearly  outline  the  limitations	 and
possible operational  impact of	 high-bandwidth	 real-time services  on	 the
Internet and other network services.

This document defines a	packet format shared by	two protocols:


  o the	real-time  transport protocol  (RTP),  for exchanging  data that  hs
    real-time  properties.    The  RTP	header consists	 of  a	fixed-length
    portion plus optional control fields;

  o the	RTP  control protocol  (RTCP), for conveying  information about	 the
    participants  in an	 on-going  session.    RTCP consists  of  additional
    header options  that may  be ignored  without affecting  the ability  to
    receive  data correctly.	 RTCP  is used	for  ``loosely	controlled''
    sessions,  i.e.,  where there  is  no explicit  membership	control	 and
    set-up.    Its  functionality  may	be subsumed  by	 a  session  control
    protocol, which is beyond the scope	of this	document.

------------------------------
 1. For	most  applications, RTP	 offers	insufficient  demultiplexing to	 run
directly on IP.








H. Schulzrinne/S. Casner	      Expires 11/01/93		    [Page 4]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

2 RTP Protocol Use Scenarios


The following sections describe	some aspects of	the use	of RTP.	The examples
were chosen to	illustrate the	basic operation	of  applications using	RTP,
not to	limit  what RTP	 may  be  used for.    In  these  examples,  RTP  is
carried	on top	of IP and  UDP,	and follows  the conventions established  by
the profile for	audio  and video specified in  the companion Internet  draft
draft-ietf-avt-profile.



2.1 Simple Multicast Audio Conference


A working group	 of the	 IETF meets to	discuss	the  latest protocol  draft,
using the IP multicast	services of the	 Internet for voice  communications.
Through	some  allocation  mechanism,  the  working  group  chair  obtains  a
multicast group	 address;  all participants  use  the destination  UDP	port
specified by the profile.   The	multicast address and port are	distributed,
say, by	electronic mail, to all	 intended participants.	 The mechanisms	 for
discovering available multicast	addresses  and distributing the	 information
to participants	are beyond the scope of	RTP.

The audio conferencing application used	by each	conference participant sends
audio data in small  chunks of,	say, 20	 ms duration.	Each chunk of  audio
data is	preceded by an RTP header; RTP header and data are in turn contained
in a UDP packet.   The	Internet, like	other packet networks,	occasionally
loses and reorders packets and delays them by variable amounts of time.	  To
cope with these	impairments, the RTP header contains timing information	 and
a sequence number that	allow the receivers to	reconstruct the	timing	seen
by the source, so that,	 in our	case, a	chunk  of audio	is delivered to	 the
speaker	every 20 ms.  The sequence  number can also be used by the  receiver
to estimate how	many packets are being lost.  Each RTP packet also indicates
what type of  audio encoding  (such as	PCM, ADPCM  or GSM)  is	being  used,
so that	senders	can  change the	encoding during	 a conference, for  example,
to accommodate a new participant  that is connected through a  low-bandwidth
link.

Since members of the working group join	and leave during the conference,  it
is useful to know  who is participating	 at any	moment.	  For that  purpose,
each instance  of  the	audio application  in  the  conference	periodically
multicasts the name, email address and other information of its	user.	Such
control	information is	carried	as  RTCP SDES options  within RTP  messages,
with or	 without audio	data (see  Section 6.2).    These periodic  messages
also provide some indication as	to  whether the	network	connection is  still
functioning.   A  site	sends the  RTCP	BYE  (Section  6.3) option  when  it
leaves a conference.  The RTCP	QOS (Section 6.4) option indicates how	well
the current speaker is	being received and may	be used	to control  adaptive
encodings.



H. Schulzrinne/S. Casner	      Expires 11/01/93		    [Page 5]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

2.2 Bridges


So far,	we have	 assumed that all  sites want to receive  audio	data in	 the
same format.	However,  this may  not	 always	be  appropriate.    Consider
the case where participants  in	one area are  connected	through	a  low-speed
link to	the majority  of the conference	 participants, who enjoy  high-speed
network	access.	   Instead of  forcing everyone	 to use	 a  lower-bandwidth,
reduced-quality	audio encoding,	 a ______ is  placed near the  low-bandwidth
area.  This bridge resynchronizes incoming audio packets to reconstruct	 the
constant 20 ms spacing	generated by the  sender, mixes	these  reconstructed
audio streams, translates the  audio encoding to  a lower-bandwidth one	 and
forwards the lower-bandwidth packet stream to the low-bandwidth	sites.

After the mixing, the identity of  the high-speed site that is speaking	 can
no longer be determined	from the network  origin of the	packet.	  Therefore,
the bridge inserts a CSRC option (Section 5.2.1) into the packet  containing
a list of short	site  identifiers to indicate which site(s)  ``contributed''
to that	mixed packet.  An example of this is shown for bridge B1 in  Fig. 1.
As name	and location information is  received by the bridge in SDES  options
from the high-speed sites,  that information is	passed	on to the  receivers
along with a mapping to	the CSRC identifiers.



      [E1]				      [E6]
       |				       |
 E1:17 |				 E6:15 |
       |				       |   E6:63/6
       V   B1:48 (1,2)	       B1:28/1 (1,2)   V   B1:63/5 (1,2)
      (B1)-------------><T1>-----------------><T2>--------------->[E7]
       ^		 ^     E4:28/2	       ^   E4:63/3
  E2:1 |	   E4:47 |		       |   B3:63/4 (1,4)
       |		 |		       |
      [E2]		[E4]		       |
					       |	    LEGEND:
[E3] --------->(B2)----------->(B3)------------|	  [End system]
       E3:64	    B2:12 (3)	^			  (Bridge)
				| E5:45			  <Translator>
				|
			       [E5]	content: source	port/SSRC (CSRCs)
					-------------------------------->
  Figure 1:  Sample RTP	network	with end systems, bridges and translators



2.3 Translators


Not all	 sites are  directly accessible	 through IP  multicast.	  For  these
sites, mixing  may  not	 necessary,  but a  translation	 of  the  underlying
transport protocol is.	 RTP-level  gateways that do  not restore timing  or

H. Schulzrinne/S. Casner	      Expires 11/01/93		    [Page 6]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

mix packets from different sources are called ___________ in this  document.
Application-level firewalls, for example, will not let any IP packets  pass.
Two translators	 are installed,	 one on	 either	side  of the  firewall,	 the
outside	one  funneling all  multicast packets  received	through	 the  secure
connection to the  translator inside the  firewall.   The translator  inside
the firewall sends  them again	as multicast  packets to  a multicast  group
restricted to  the site's  internal network.	Other examples	include	 the
connection of a	group of hosts speaking	only IP/UDP to a group of hosts	that
understand only	ST-II.

After RTP  packets have	 passed	through	 a translator,	they all  carry	 the
network	source	address	of  the	translator,  making  it	impossible  for	 the
receiver to distinguish	 packets from  different speakers  based on  network
source addresses.    Since each	 sending site  has its	own sequence  number
space and slightly offset timestamp  space, the	receiver could not  properly
mix the	audio  packets.	  (For video,  it could	not  properly separate	them
into distinct displays.)   Instead  of forcing all  senders to include	some
globally unique	identifier  in each  packet,  a	translator  inserts an	SSRC
option (Section	 5.2.2)	with  a	 short identifier  for	the source  that  is
locally	unique to the translator.  This	 also works if an RTP packet has  to
travel through several translators, with the SSRC value	being mapped into  a
new locally unique value at each translator.  An example is shown in Fig. 1,
where hosts T1 and  T2 are translators.	  The RTP packets  from	host E4	 are
identified with	SSRC value 2, while those coming from bridge B1	are  labeled
with SSRC value	1.  Similarly, translator T2 labels packets from E6, B1,  E4
and B3 with SSRC values	 6, 5, 3 and 4,	 respectively (or some other  unique
values).



2.4 Security


Conference participants	 would often  like to  ensure that  nobody else	 can
listen to their	deliberations.	Encryption, indicated by the presence of the
ENC option (Section 5.4.1),  provides that privacy.   The encryption  method
and key	can be changed during the conference by	indexing into a	table.	 For
example, a meeting may go into	executive session, protected by	a  different
encryption key accessible only to a subset of the meeting participants.

For authentication, a number of	methods	are provided, depending	on needs and
computational capabilities.  All these message integrity check (MIC) options
(Sections 5.4.3	and following)	compute	cryptographic checksums, also  known
as message digests, over the RTP data.


3 Definitions


_______	is the data following the RTP fixed header and the RTP/RTCP options.
The payload format  and	interpretation are  beyond the scope  of this  memo.


H. Schulzrinne/S. Casner	      Expires 11/01/93		    [Page 7]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

RTP packets without payload  are valid.	  Examples of payload include  audio
samples	and video data.

An ___	______	consists  of  the encapsulation	 specific  to  a  particular
underlying protocol, the fixed RTP header, RTP and RTCP	options	(if any) and
the payload, if	any.  A	single packet of the underlying	protocol may contain
several	RTP packets if permitted by the	encapsulation method.

A __________  ____ is  the  ``abstraction that	transport protocols  use  to
distinguish among  multiple  destinations  within  a  given  host  computer.
TCP/IP protocols identify  ports using	small positive	integers.'' [1]	 The
transport selectors (TSEL) used	by the OSI transport layer are equivalent to
ports.

A _________ _______ denotes  the combination of	 network address, e.g.,	 the
4-octet	IP Version 4 address, and the transport	protocol port, e.g., the UDP
port.  In  OSI systems,	 the transport address	is called transport  service
access point or	TSAP. The destination transport	address	may be a unicast  or
multicast address.

A _______  ______  is the  actual  source of  the  data	carried	 in  an	 RTP
packet,	for example,  the application that  originally generated some  audio
data.  Data from one or	more  content sources may be combined into a  single
RTP packet by a	bridge,	which  becomes the synchronization source (see	next
paragraph).  Content  sources identify the logical  source of the data,	 for
example, to highlight the current speaker in an	audio conference; they	have
no effect on the delivery or playout timing of the data	itself.	 In  Fig. 1,
E1 and E2 are the content sources of the data received by E7 from bridge B1,
while B1 is the	synchronization	source.

A _______________ ______ is the	combination  of	one or more content  sources
with its  own timing.	 Each synchronization  source has  its own  sequence
number space.	The  audio coming  from	a  single microphone  and the  video
from a	camera	are examples  of  synchronization  sources.    The  receiver
groups packets by synchronization source for  playback.	 Typically a  single
synchronization	source emits  a	single	medium (e.g.,  audio or	video).	   A
synchronization	source may  change its	data format,  e.g., audio  encoding,
over time.    Synchronization  sources	are identified	by  their  transport
address	and the	identifier carried in the  SSRC	option.	 If the	SSRC  option
is absent, a value of zero is assumed for that identifier.

A _________ ______ is the transport-level origin of the	RTP packets as	seen
by the receiving end system.  In  Fig. 1, host T2, port	63 is the  transport
source of all packets received by end system E7.

A  _______  comprises  all  synchronization  sources  sending  to  the	same
destination transport address using the	same RTP channel identifier.

An ___ ______ generates	the content to	be sent	in RTP packets and  consumes
the content  of	 received  RTP.	 An  end system	 can  act  as  one  or	more
synchronization	sources.   (Most  end systems are  expected to	be a  single


H. Schulzrinne/S. Casner	      Expires 11/01/93		    [Page 8]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

synchronization	source.)

An (RTP-level)	______	receives  RTP  packets from  one  or  more  sources,
combines them in some manner and then forwards	a new RTP packet.  A  bridge
may change the data format.   Since the	timing among multiple input  sources
will not generally be synchronized, the	bridge will make timing	 adjustments
among the  streams and	generate its  own timing  for the  combined  stream.
Therefore, bridges are	synchronization	sources,  with each  of	the  sources
whose packets  were combined  into an  outgoing	RTP  packet as	the  content
sources	for that outgoing  packet.  Audio  bridges and media converters	 are
examples of bridges.  In Fig. 1,  end systems E1 and E2	use the	services  of
bridge B1.  B1 inserts CSRC identifiers	 for E1	and E2 when they are  active
(e.g., talking in an audio conference).	 The RTP-level bridges described  in
this document are unrelated  to	the data link-layer  bridges found in  local
area networks.	If there  is possibility for confusion,	the term  'RTP-level
bridge'	should be used.	  The name  bridge follows common  telecommunication
industry usage.

An (RTP-level) __________  forwards RTP	packets,  but does  not	alter  their
sequence numbers  or timestamps.    Examples  of  its use  include  encoding
conversion without mixing or retiming, conversion from multicast to unicast,
and application-level  filters in  firewalls.	A  translator is  neither  a
synchronization	nor  a	content	source.	    The	properties  of	bridges	 and
translators are	summarized in Table 1.	Checkmarks in parentheses  designate
possible, but unlikely actions.	 The options are explained in Sections	5.2,
the RTCP options in Section 6.



				    end	sys.  bridge  translator
	   mix sources		       --	 x	  --
	   change encoding	       N/A	 x	  x
	   encrypt			x	 x	 (x)
	   sign	for authentication	x	 x	  --
	   alter content		x	 x	  x
	   insert CSRC (RTP)	       --	 x	  --
	   insert SSRC (RTP)		x	 x	  x
	   insert SDST (RTP)		x	 x	  --
	   insert SDES (RTCP)		x	 x	  --


      Table 1:	The properties of end systems, bridges and translators

A _______________ ____	consists of  one or  more packets  that	are  emitted
contiguously by	 the sender.	The most  common synchronization  units	 are
talkspurts for voice  and frames  for video  transmission.   During  playout
synchronization, the receiver must  reconstruct	exactly	the time  difference
between	packets	within a synchronization unit.	The time difference  between
synchronization	units may be changed by	the receiver to	compensate for clock
drift or to adjust to changing network delay jitter.  For example, if  audio
packets	are generated  at fixed	 intervals during  talkspurts, the  receiver
has to play back packets  with exactly the same	spacing.   However, if,	 for

H. Schulzrinne/S. Casner	      Expires 11/01/93		    [Page 9]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

example, a silence period  between synchronization units (talkspurts)  lasts
600 ms,	 the receiver  may adjust  it to,  say,	 500 ms	 without this  being
noticed	by the listener.

_______	__________  refers to  other protocols	and mechanisms	that may  be
needed to  provide  a  useable	service.    In	particular,  for  multimedia
conferences, a conference control application may distribute encryption	 and
authentication keys,  negotiate	the  encryption	algorithm  to be  used,	 and
determine the mapping from  the	RTP format field  to the actual	data  format
used.  For simple applications,	electronic mail	or a conference	database may
also be	used.  The specification of such mechanisms is outside the scope  of
this memorandum.



4 Byte Order, Alignment, and Reserved Values


All integer  fields  are  carried in  network  byte  order,  that  is,	most
significant byte  (octet) first.    This  byte order  is commonly  known  as
big-endian.  The transmission order is described in detail in [2],  Appendix
A. Unless  otherwise noted,  numeric  constants	are  in	decimal	 (base	10).
Numeric	constants prefixed by '0x' are in hexadecimal.

Fields within the fixed	header and within options are aligned to the natural
length of  the field,  i.e., 16-bit  words are	aligned	 on even  addresses,
32-bit long words are aligned at addresses  divisible by four, etc.   Octets
designated as padding have the value zero.

Textual	information is	encoded	accorded to  the UTF-2 encoding	 of the	 ISO
standard 10646 (Annex F) [3,4].	 US-ASCII  is a	subset of this encoding	and
requires no additional encoding.   The presence	of multi-octet encodings  is
indicated by setting the most significant bit to  a value of one.  An  octet
with a binary value of zero may	 be used as a string terminator	for  padding
purposes.  However, strings are	not required to	be zero	terminated.


5 Real-Time Data Transfer Protocol -- RTP



5.1 RTP	Fixed Header Fields


The RTP	header has the following format:


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| ChannelID	|P|S|  format	|	sequence number		|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 10]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

|     timestamp	(seconds)	|     timestamp	(fraction)	|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| options ...							|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


The first  eight  octets  are present  in  every  RTP packet  and  have	 the
following meaning:


protocol version: 2 bits
    Identifies the  protocol version.	The version  number of the  protocol
    defined in this memo is one	(1).

channel	ID: 6 bits
    The	channel	 identifier  field forms  part of  the tuple  identifying  a
    channel (see definition in Section 3) to provide an	additional  level of
    multiplexing at  the RTP  layer.   The  channel ID	field is  convenient
    if several	different  channels are	 to receive  the same  treatment  by
    the	underlying layers  or if a profile  allows for the concatenation  of
    several RTP	packets	 on different channels into  a single packet of	 the
    underlying protocol	layer.

option present bit (P):	1 bit
    This flag has a value of one (1) if	the fixed RTP header is	 followed by
    one	or more	options	and a value of zero otherwise.

end-of-synchronization-unit (S): 1 bit
    This flag has  a value of  one in the last	packet of a  synchronization
    unit, a value of  zero otherwise.[As shown in Appendix A, the  beginning
    of a  synchronization unit can  be readily established  from this  flag.
    If this  flag were	to signal the  beginning of  a synchronization	unit
    instead, the end of	 a synchronization unit	could not be established  in
    real time.]

format:	6 bits
    The	 format	field  forms  an index	into  a	table  defined	through	 the
    RTCP  FMT  option  or   non-RTP  mechanisms	 (see  Section	3).	 The
    mapping establishes	 the format of	the RTP	payload	 and determines	 its
    interpretation by  higher layers.	If  no mapping has  been defined  in
    this manner,  a standard mapping is	 specified by the companion  profile
    document, RFC TBD. Also,  default formats may be defined by	the  current
    edition of the Assigned Numbers RFC.

sequence number: 16 bits
    The	sequence number	counts RTP packets.  The sequence  number increments
    by one  for	 each packet  sent.   The  sequence number  may	be  used  by
    the	receiver to  detect packet loss, to  restore packet sequence and  to
    identify packets to	the application.

timestamp: 32 bits


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 11]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

    The	timestamp  reflects the	 wall clock  time  when	the  RTP packet	 was
    generated.	 Several consecutive RTP  packets may have equal  timestamps
    if they are	generated at once.  The	timestamp consists of the  middle 32
    bits of a 64-bit  NTP timestamp, as	defined	in  RFC	1305 [5].  That	 is,
    it counts  time since 0 hours  UTC,	January	1,  1900, with a  resolution
    of	65536  ticks per  second.    (UTC  is  Coordinated  Universal  Time,
    approximately equal	 to the	historical  Greenwich Mean Time.)   The	 RTP
    timestamp wraps around approximately every 18 hours.

    The	timestamp  of  the first  packet within	 a synchronization  unit  is
    expected  to  closely reflect  the	actual	sampling  instant,  measured
    by	the local  system  clock.    If	 possible, the	local  system  clock
    should be  controlled by a	time synchronization protocol  such as	NTP.
    However,  it  is  allowable	to  operate  without  synchronized  time  on
    those systems  where it is	not available, unless  a profile or  session
    protocol requires  otherwise.   It	is  not	necessary  to reference	 the
    local  system  clock  to obtain  the  timestamp  for  the  beginning  of
    every synchronization  unit, but  the local	clock  should be  referenced
    frequently enough  so that clock drift  between the	synchronized  system
    clock and the sampling clock  can be compensated for gradually.   Within
    one	synchronization	 unit, it may be  appropriate to compute  timestamps
    based on  the logical  timing relationships	between	 the packets.	 For
    audio samples, for example,	the nominal sampling interval may be used.



5.2 The	RTP Options


The packet  header  may	 be  followed  by  options  and	 then  the  payload.
Each option consists  of the  F	(final)	 bit, the  option type	designation,
a  one-octet  length  field  denoting  the  total  number  of  32-bit  words
comprising the option (including  F bit, type and  length), followed by	 any
option-specific	data.  The last	option before the payload has the F bit	 set
to one;	for all	other options this bit has a value of zero.

An application	may discard  options with  types  unknown to  it.    Private
and experimental options  should use option  types 64 through  127.   Fields
designated as  ``reserved'' or	``R'' are  set aside  for future  use;	they
should be set to zero by senders and ignored by	receivers.

Unless otherwise noted,	each option may	appear	only once per packet.	Each
packet may contain any number of options.  Options may appear in any  order,
unless specifically restricted by  the option description.   In	 particular,
the position of	some security options may have significance.

The RTP	options	have the following type	values:






H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 12]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

name  value
CSRC	  0
SSRC	  1
SDST	  2
BOS	  3
ENC	  8
MIC	  9
MICA	 10
MICK	 11
MICS	 12



5.2.1 CSRC: Content source identifiers


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|    CSRC	|    length	| content source identifier    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The content source option, inserted only by bridges, lists all sources	that
contributed to the packet.  For	example, for audio packets, all	sources	that
were mixed together to create  this packet are enumerated, allowing  correct
talker indication at the receiver.  Each CSRC option may contain one or	more
16-bit content source identifiers.  The	identifier values must be unique for
all content sources received from  a particular	synchronization	source on  a
particular channel;  the value of  binary zero	is reserved and	 may not  be
used.  If the  number of content sources is  even, the two octets needed  to
pad the	list to	 a multiple of four  octets are	set to	zero.  There  should
only be	a single CSRC option within a packet.  If no CSRC option is present,
the content source  identifier is assumed  to have a  value of zero.	CSRC
options	are not	modified by RTP-level translators.

A conformant RTP  implementation does  not have	to  be able  to	generate  or
interpret the CSRC option.



5.2.2 SSRC: Synchronization source identifier


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|    SSRC	|  length = 1	|	   identifier		|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The SSRC option	may  be	inserted by RTP-level  translators, end	systems	 and
bridges.   It is  typically used only  by translators,	but it	may be	used
by an end system  application to distinguish several  sources sent with	 the

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 13]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

same transport source address.	 Multiple  synchronization sources with	 the
same transport	source address	(e.g., the  same IP  address and  UDP  port)
must each insert a  distinct SSRC identifier.	Conversely,  synchronization
sources	that are distinguishable by  their transport address do	not  require
the use	of  SSRC options.   The	SSRC  value zero is  reserved; the  receiver
treats the packet  as if  the SSRC  option were	 not present.	 If no	SSRC
option is present, the transport source	 address is assumed to indicate	 the
synchronization	source.	  There	must  be no  more than one  SSRC option	 per
packet;	thus, a	 translator must remap	the SSRC  identifier of	an  incoming
packet into a new, locally unique SSRC	identifier.  The SSRC option can  be
viewed as an  extension	of  the	source port  number in	protocols like	UDP,
ST-II or TCP.

An RTP receiver	 must support the  SSRC	option.	  RTP senders  only need  to
support	this option if they intend to send more	than one source	to the	same
channel	using the same source port.



5.2.3 BOS: Beginning of	synchronization	unit


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|	BOS	|   length = 1	|	 sequence number	|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The sequence number within the options	contains the sequence number of	 the
first packet within the	current	synchronization	unit.  The BOS option allows
the receiver to	compute	the offset of a	packet with respect to the beginning
of the	synchronization	 unit,	even if	 the  last packet  of  the  previous
synchronization	unit was lost.	 It is expected	that many applications	will
be able	to tolerate such a loss, and so	will not use the BOS option but	rely
on the S bit.




5.3 Reverse-Path Option


With two-party (unicast)  communications, having  a receiver  of data  relay
back control information to the	sender	is straightforward.  Similarly,	 for
multicast communications,  control information	can easily  be sent  to	 all
members	of the	group.	 It may,  however, be  desirable to  send a  unicast
message	to a  single member  of	a multicast  group, for	 example to  request
retransmission of a  particular	data  frame or to  request/send	a  reception
quality	report.	  For  this particular	use,  RTP includes  a mechanism	 for
sending	so-called reverse RTP packets.	The format of reverse RTP packets is
exactly	the same as  for regular RTP  packets and they can  make use of	 all
the options defined in	this memorandum, except	SSRC,  as appropriate.	 The

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 14]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

support	for and	 semantics of particular  options are to  be specified by  a
profile.  Reverse RTP packets travel through the same translators as forward
RTP packets.   A  site distinguishes reverse  RTP packets  from	forward	 RTP
packets	by their  arrival port.	   Reverse RTP	packets	arrive	on the	same
port that the site  uses as a  source port for	forward	(data) RTP  packets.
Only reverse RTP packets carry the SDST	 option; if RTP	packets	are  carried
directly within	IP  or other network-layer  protocols, the  presence of	 the
SDST option signals that the packet is a reverse RTP packet.

A receiver of  reverse RTP  packets cannot  rely on  sequence numbers  being
consecutive, as	a sender  is allowed to	use  the same sequence number  space
while communicating  through this  reverse  path with  several	sites.	  In
particular, a receiver of  reverse RTP packets cannot  tell by the  sequence
numbers	whether	it has	received all reverse  RTP packets sent to  it.	 The
sequence number	space of reverse RTP  packets has to be	completely  separate
from that  used	for  RTP  packets sent	to  the	multicast  group.    If	 the
same sequence number  space were used,	the members of	the multicast  group
not receiving  reverse RTP  packets would  detect a  gap in  their  received
sequence number	space.	  The sender of	 reverse RTP  packets should  ensure
that sequence numbers  are unique,  modulo  wrap-around, so  that they	can,
if necessary,  be  used	for  matching request  and  response.	 (Currently,
no such	request-response  mechanism has	been  defined.)	  As a	hypothetical
example, consider  defining  a	request	 to pan	 the  remote  video  camera.
After completing  the request,	the receiver  of the  request would  send  a
generic	acknowledgement	containing  the	sequence  number of  the request  to
the requestor as an option (not	as  the	packet sequence	number in the  fixed
header).

The timestamp should  reflect the  approximate sending time  of	the  packet.
The channel identifier must  be	the same as  that used in the  corresponding
forward	RTP packets.

If many	receivers send	a reverse RTP  packet in response  to a	stimulus  in
the data stream,  the simultaneous  delivery of	 a large  number of  packets
back to	the data source	 can cause congestion for  both	the network and	 the
destination (this  is known  as	an  ``ack implosion'').	   Thus	reverse	 RTP
packets	should be used with care,  perhaps with	mechanisms such	as  response
rate limiting and random delays	to spread out the simultaneous delivery.


5.3.1 SDST: Synchronization destination	identifier


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|    SDST	|   length = 1	|	    identifier		|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The SDST option	is only	inserted by RTP	end systems and	bridges	if they	want
to send	unicast	information to a particular site within	the multicast group.


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 15]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

Packets	containing an SDST option must	not contain an SSRC option and	vice
versa.	 Packets containing a  SDST option are	always reverse RTP  packets.
The SDST option	may be used to distinguish reverse RTP packets from  forward
RTP packets if the port-number	mechanism described earlier in this  section
is not available, e.g.,	because	RTP  packets are carried directly within  IP
packets, without UDP.

If a  forward RTP  packet carries  SSRC	identifier  X when  sent from  A  to
B, where A  and	B  may be  either two  translators or  an end  system and  a
translator, the	unicast	reverse	 RTP packet will carry	an SDST	option	with
identifier X from B to A.

Consider the topology shown in Fig. 1.	Assume that all	forward	RTP  packets
are addressed to destination port 8000.	 For the case that B1 wants  to	send
a reverse packet to E1,	B1 simply sends	to the source address and port,	that
is, port 17 in this example.  E1 can tell by the arrival on port 17 that the
packet is a reverse packet rather than a regular (forward) packet.

The mechanism is somewhat more complicated  when translators intervene.	  We
focus on end system E7.	  E7 receives, say,  video from	a range	of  sources,
E1 through E6  as indicated  by	the  arrows.   The transmission	 from T2  to
E7 could be either  multicast or unicast.   Assume that	E7  wants to send  a
retransmission request,	a request to pan the camera, etc., to end system  E4
and only to E4.	 E7 may	not be able to directly	reach E4, as E4	may be using
a network protocol unknown to E7 or be located behind a	firewall.  According
to the figure, video transmissions from	 E4 reach E7 through T2	with  source
port 63	and SSRC identifier 3.	For the	reverse	message, E7 sends  a message
to T2, with destination	port 63	 and SDST identifier 3.	  T2 can look up  in
its table that	it sends forward  data coming from  T1 with that  identifier
3.   T2	also  knows that  those	messages  from T1  carry SSRC  2 and  arrive
with source port 28.   Just  like E7,  T2 places the  SSRC identifier, 2  in
this case, into	the SDST  option and forwards the packet  to T1	at port	 28.
Finally, translator T1	consults its table  to find that  it labels  packets
coming from E4,	 port 47 with  SSRC value 2  and thus  knows to	forward	 the
reverse	packet to E4, port 47.	 T1 can	either	place SDST value zero or  no
SDST option into that packet.	Note that E4 cannot directly determine	that
E7 sent	the reverse packet, rather than, say,  E6.  If that is important,  a
global identifier as defined for the QOS option	needs to be included in	 the
reverse	packet.

Only applications that need to send  or	receive	reverse	control	RTP  packets
need to	implement the SDST option.




5.4 Security Options


The security  options  below offer  message  integrity,	 authentication	 and
privacy	and  the  combination  of the  three.	 Support  for  the  security
options	is not mandatory, but  see the discussion for the  ENC option.	 The

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 16]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

four message integrity check  options --- MIC, MICA,  MICK and MICS ---	 are
mutually exclusive, i.e., only	one of them should be  used in a single	 RTP
packet.

Combinations of	one of the message integrity check options (MIC, MICA, MICK,
or MICS) and  the encryption  (ENC) option described  below can	 be used  to
provide	a variety of security services:



confidentiality: Confidentiality  means	that only  the intended	 receiver(s)
    can	 decode	 the received  RTP  packets;  for  others,  the	 RTP  packet
    contains no	 useful	 information.	Confidentiality	 of the	 content  is
    achieved by	encryption.   The presence of encryption and the  encryption
    initialization vector  is indicated	 by the	 ENC option.[For  efficiency
    reasons,  this specification  does not  insist that	 content  encryption
    only be  used in conjunction with  message integrity and  authentication
    mechanisms.	 In most  cases, it will be obvious to the person  receiving
    the	data if	he or she does not possess the right encryption	key.]

authentication and message integrity: In  combination with  certificates(2),
    the	receiver  can ascertain	that  the claimed originator  is indeed	 the
    originator	of the	data  (authentication) and  that  the data  has	 not
    been  altered after	 leaving  the sender  (message	integrity).    These
    two	 security services  are	 provided  by the  message  integrity  check
    options.	Certificates  for MICA	must  be distributed  through  means
    outside of RTP. The	 services offered by MICA and MIC/MICK/MICS  differ:
    With  MIC/MICK/MICS, the  receiver	can  only verify  that	the  message
    originated	within	the  group  holding  the  secret key,	rather	than
    authenticate the sender  of	the message,  while the	MICA option  affords
    true authentication	of the sender.

authentication,	message	integrity, and confidentiality:	By   carrying	both
    the	 message  integrity  check  and	 ENC  option  in RTP  packets,	 the
    authenticity, message  integrity and confidentiality  of the packet	 can
    be	assured	 (subject to  the  limitations	discussed  in  the  previous
    paragraph).

    The	 message integrity  check  is applied  first  to all  parts  of	 the
    outgoing packet  to	be  authenticated, and the  message integrity  check
    option is  prepended to  those parts.    Then the  packet including	 the
    message integrity  check option  is	 encrypted using  the shared  secret
    key.    The	ENC  option  must be  followed	immediately by	the  message
    integrity check  option,  without any  other options  in between.	 The
    receiver first  decrypts the octets	 following the ENC  option and	then
    authenticates the  decrypted data using the	 signature contained in	 the
    message integrity check option.

    For	this combination of security features and group	authentication,	 the
------------------------------
 2. For	a description of certificates see, for example,	RFC 1422 or [6].


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 17]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

    combination	ENC and	MIC is recommended (instead of MICS or MICK),  as it
    yields the lowest processing overhead.



A message integrity  check option followed  by an ENC  option should not  be
used.	All  message integrity	check options  are computed  over the  fixed
header,	the first four octets of the message integrity check option and	 the
data, that is,	the remaining  header options  and payload  that follow	 the
message	integrity check	 option.   The MICK option  includes the whole	MICK
option itself in the message integrity check.  The fixed header	is protected
to foil	replay attacks and reassignment	to a different channel.

The message  integrity check  options and  the ENC  option shall  not  cover
the SSRC and  SDST options,  i.e., SSRC	 and SDST must	be inserted  between
the fixed header and the  ENC or message integrity  check options; SSRC	 and
SDST are subject  to change by	translators that likely	 do not	possess	 the
necessary descriptor table  (see below)	 and encryption	keys.	 Translators
that have the  necessary keys  and descriptor translation  table may  modify
the contents of	the  RTP packet, unless	 the MICA option  is used (see	MICA
description in Section 5.4.3).

All security options carry  a one-octet	descriptor field.   This  descriptor
is an index into  two tables, one for  the message integrity check  options,
one for	the  ENC option,  established  by non-RTP means,  containing  digest
algorithms (MD2,  MD5,	etc.),	encryption  algorithms	(DES  variants)	 and
encryption keys	 or shared  secrets (for  the  MICK option).	All  sources
within the same	channel	 share the same	table;	this reduces per-site  state
information.  The descriptor value may change during a session,	for example,
to switch to a different encryption key.

The descriptor value zero selects a  set of default algorithms,	namely,	 MD5
for the	message	digest algorithm, DES CBC for the encryption algorithm.


5.4.1 ENC: Encryption


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|	ENC	|   length = 3	|    reserved	|   descriptor	|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      DES (CBC) initialization	vector,	bytes 0	through	3	|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      DES (CBC) initialization	vector,	bytes 4	through	7	|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|	ENC	|   length = 1	|    reserved	|   descriptor	|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 18]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

All packet data	after this option is encrypted,	using the encryption key and
symmetric encryption algorithm	specified by  the descriptor field.    Every
encrypted RTP packet must contain this option.	 Note that the fixed  header
is specifically	not  encrypted because	some fields must  be interpreted  by
translators that will not have access to the key.  The descriptor value	 may
change over time to accommodate	 varying security requirements or limit	 the
amount of ciphertext using the	same key.  For	example, in a job  interview
conducted across a network, the	 candidate and interviewers could share	 one
key, with a second key set aside  for the interviewers only.  For  symmetric
keys, source-specific keys offer no advantage.

The descriptor value  zero is  reserved	for a  default mode  using the	Data
Encryption Standard (DES)  algorithm in	 CBC (cipher  block chaining)  mode,
as described  in  Section 1.1  of  RFC 1423  [7].    The  padding  specified
in that	section	 is to	be used.    The	8-octet	 initialization	vector	(IV)
may be carried unencrypted  within the ENC option,  generated anew for	each
packet.	   If the  ENC	option does  not  contain an  initialization  vector
(indicated by an option	length of one),	the fixed RTP header is	used as	 the
initalization vector.	(Using the  fixed RTP header  as the  initialization
vector avoids regenerating  the	initialization	vector for  each packet	 and
incurs less  header  overhead.)	   For	details	 on the	 tradeoffs  for	 CBC
initialization vector use, see [8].  Support for encryption is not required.
Implementations	that  do not  support encryption  should recognize  the	 ENC
option so  that	they  can avoid	 processing encrypted  messages	and  provide
a meaningful failure  indication.   Implementations that support  encryption
should,	at the minimum,	always support the DES CBC algorithm.



5.4.2 MIC: Messsage integrity check


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|	MIC	|     length	|    reserved	|   descriptor	|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|		  message digest (unencrypted)		       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The  MIC  option  option   is  used  only  in	combination  with  the	 ENC
option immediately  preceding it  to provide  privacy and  group  membership
authentication.	  The  message	integrity check	 uses the  digest  algorithm
specified by the  descriptor field.   (A message  digest is a  cryptographic
hash function that  transforms a  message of  any length  to a	fixed-length
byte string,  where the	 fixed-length string  has the  property	that  it  is
computationally	infeasible to generate	another, different message with	 the
same digest.)	The value zero	implies	the use	of  the	MD5 message  digest.
Note that the MIC option is not	separately encrypted.



H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 19]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

5.4.3 MICA: Message integrity check, asymmetric	encryption


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|    MICA	|    length	|	  message digest       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|		     (asymmetrically encrypted)		       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Currently, only	the  use of  the MD2  and MD5 message  digest algorithms  is
defined, as described in RFC  1319 [9] (as corrected  in Section 2.1 of	 RFC
1423) and RFC 1321 [10], respectively.	The MD2	and MD5	message	digests	 are
16 octets long.

RFC 1423, Section 2.1:



    To	avoid any  potential ambiguity	regarding the  ordering	 of the
    octets of  an MD2  message	digest that  is	input  as a  data value
    to another encryption process  (e.g., RSAEncryption), the following
    holds true.	  The first  (or left-most displayed, if  one thinks in
    terms of a	digest's ``print'' representation) octet  of the digest
    (i.e.,  digest[0] as  specified in	RFC 1319),  when  considered as
    an RSA  data value,	 has  numerical	weight	2**120.	  The  last (or
    right-most displayed) octet	 (i.e.,	digest[15] as  specified in RFC
    1319) has numerical	weight 2**0.


RFC 1423, Section 2.2:


    To	avoid any  potential ambiguity	regarding the  ordering	 of the
    octets of an MD5 message digest that  is input as an RSA data value
    to the  RSA	 encryption process,  the following  holds true.    The
    first (or left-most	displayed, if one thinks in terms of a digest's
    ``print'' representation) octet of	the digest (i.e., the low-order
    octet of  A	as specified  in RFC 1321),  when considered as	 an RSA
    data value,	has  numerical weight 2**120.	The last (or right-most
    displayed) octet (i.e.,  the high-order octet of D	as specified in
    RFC	1321) has numerical weight 2**0.


The message digest is  encrypted, using	asymmetric  keys, with the  sender's
private	key using the algorithm	described in Section 4.2.1 of RFC 1423:



    As described in PKCS #1, all quantities input as data values to the
    RSAEncryption process shall	be properly justified and padded to the

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 20]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

    length of the modulus prior	to the encryption process.  In general,
    an RSAEncryption input  value is formed by	concatenating a	leading
    NULL octet,	a block	type BT, a padding string PS, a	NULL octet, and
    the	data quantity D, that is, RSA input value = 0x00, BT, PS, 0x00,
    D. To  prepare a MIC  for RSAEncryption,  the PKCS #1  ``block type
    01'' encryption-block  formatting scheme  is employed.    The block
    type BT is a single	octet containing the value 0x01	and the	padding
    string PS is one  or more octets (enough octets  to	make the length
    of the complete RSA	input value equal to the length	of the modulus)
    each containing the	value 0xFF. The	data quantity D	is comprised of
    the	MIC and	the MIC	algorithm identifier.



The encoding is	described  in detail in	 RFC 1423.   For encrypting MD2	 and
MD5, the data quantity	D comprises the	16-octet  checksum, preceded by	 the
binary sequences shown here in hexadecimal:   0x30, 0x20, 0x30,	0x0C,  0x06,
0x08, 0x2A, 0x86, 0x48,	0x86, 0xF7, 0x0D, 0x02,	0x02, 0x05, 0x00, 0x04,	0x10
for MD2	and  0x30, 0x20,  0x30,	0x0C, 0x06,  0x08, 0x2A,  0x86,	0x48,  0x86,
0xF7, 0x0D, 0x02, 0x05,	0x05, 0x00, 0x04, 0x10 for MD5.

Contrary to what is  specified in RFC  1423 for	privacy	 enhanced mail,	 the
asymmetrically signed  MIC is  carried in  binary,  ___	represented  in	 the
printable encoding of RFC  1421, Section 4.3.2.4.   The	encrypted length  of
the signature  will be	equal to  the modulus  of the  RSA encryption  used,
rounded	to the next integral  octet count.  The	 modulus and public key	 are
conveyed to the	receivers by non-RTP means.  Asymmetric	keys are used  since
symmetric keys would not  allow	authentication of  the individual source  in
the multicast case.

The signature is  padded as necessary.	 The  value of the  padding is	left
unspecified.  The number of  non-padding bits within the signature is  known
to the receiver	 as being equal	 to the	key  length.   The MIC algorithm  is
identified through the octets prepended	to the actual 16-octet signature.

A translator is	not  allowed to	modify	the parts of  an RTP packet  covered
by the MICA option  as the receiver  would have	no  way	of establishing	 the
identity of the	translator  and	thus could not	verify the integrity of	 the
RTP packet.

Support	for sending or interpreting MICA options is not	required.



5.4.4 MICK: Message integrity check, keyed


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|    MICS	|    length	|   reserved	|   descriptor	|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 21]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

|	    message digest (symmetrically encrypted)	       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This message  integrity	 check option  does  not  require encryption.	  In
addition to  the RTP  packet parts  to	be included  in	the  message  digest
according to the introduction to this  section,	the shared secret is  placed
in the MICK option and included	in the message digest.	The shared secret is
equivalent to the key used  for	the MICS and ENC  options, but is 16  octets
long, padded if	needed with  binary zeroes.  The  shared secret	in the	MICK
option is then replaced	by the computed	16-octet message digest.

The receiver  stores  the  message  digest contained  in  the  MICK  option,
replaces it with the  shared secret key	and  computes the message digest  in
the same manner	 as the	sender.	  If  the RTP packet  has not been  tampered
with and has originated	with  one of the holders  of the shared	secret,	 the
computed message digest	 will agree with  the digest found  on reception  in
the MICS option.[The message  integrity	check follows  the practice of	SNMP
Version	2, as described	in RFC 1446, Section 1.5.1.  The MICS option  itself
is covered by the  digest in order to  detect tampering	with the  descriptor
field itself.  Using the secret	 key in	the signature instead of  encrypting
the MD5	message	digest avoids the  use of an encryption	algorithm when	only
authentication is desired.  However,  the security of this approach has	 not
been as	well established as  the authentication	based on encrypting  message
digests	used in	the MICS, MIC and MICA options.]



5.4.5 MICS: Message integrity check, symmetric-key encrypted


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|    MICS	|    length	|   reserved	|   descriptor	|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|	    message digest (symmetrically encrypted)	       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This message integrity check encrypts the message digest using DES ECB	mode
as described in	RFC 1423, Section 3.1.




6 Real Time Control Protocol --- RTCP


The real-time control protocol (RTCP)  conveys minimal control and  advisory
information  during  a	session.      It  provides  support  for   ``loosely
controlled'' sessions,	i.e.,  where participants  enter and  leave  without
membership control and parameter negotiation.  The services provided by	RTCP


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 22]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

services augment RTP,  but an  end system does	not have  to implement	RTCP
features to participate	in sessions.   There is	one exception to this  rule:
if an application sends	 FMT options,  the receiver has	 to decode these  in
order to properly interpret the	RTP payload.   RTCP does not aim to  provide
the services of	 a session  control protocol and  does not  provide some  of
the services desirable for  two-party conversations.   If a session  control
protocol is in use, the	services of RTCP should	not be required.  (As of the
writing	of this	document, a session  or	conference control protocol has	 not
been specified within the Internet.)

RTCP options share the	same structure and numbering  space as RTP  options,
which are  described  in  Section  5.	  Unless  otherwise noted,   control
information is	carried	periodically  as options  within RTP  packets,	with
or without payload.   RTCP  packets are	sent  to all members  of a  session.
These packets are part of the same sequence number space as RTP	packets	 not
containing RTCP	options.    The	period should  be varied  randomly to  avoid
synchronization	of all sources and its mean should increase with the  number
of participants	in the	session	to limit the  growth of	the overall  network
and host interrupt load.  The length of	the period determines, for  example,
how long a receiver joining a session has to wait until	it can identify	 the
source.	 A receiver may	remove from its	list of	active sites a site  that it
has not	been heard from	for a given time-out period; the time-out period may
depend on the number of	sites  or the observed average interarrival time  of
RTCP messages.	Note that not every periodic message has to contain all	RTCP
options; for example, the  EMAIL part within the  SDES option might only  be
sent every few messages.  RTCP options should also be sent when	 information
carried	in RTCP	options	changes, but  the generation of	RTCP options  should
be rate-limited.

The option types are defined below:



6.1 FMT: Format	description


  0		      1			  2		      3
  0 1 2	3 4 5 6	7 8 9 0	1 2 3 4	5 6 7 8	9 0 1 2	3 4 5 6	7 8 9 0	1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|	 FMT	 |    length	 |R|R|	format	 |    reserved	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		      format-dependent data			...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


format:	6 bits
    The	format field  corresponds to the index	value from the format  field
    in the RTP fixed header, with values ranging from 0	to 63.

Format-dependent data: variable	length
    Format-dependent data  may or may  not appear in  a	FMT option.   It  is
    passed to the next layer and not interpreted by RTP.

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 23]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

A FMT mapping changes the interpretation of a given format value carried  in
the fixed RTP header starting at the packet containing the FMT option.	 The
new interpretation applies  only to  packets from  the same  synchronization
source as the  packet containing the  FMT option.   If	format mappings	 are
changed	through	the FMT	 option, the option should  be sent periodically  as
otherwise sites	that did not  receive the FMT option  due to packet loss  or
joining	the session  after the	FMT option  was	sent  will not	know how  to
interpret the particular format	value.




6.2 SDES: Source descriptor


  0		      1			  2		      3
  0 1 2	3 4 5 6	7 8 9 0	1 2 3 4	5 6 7 8	9 0 1 2	3 4 5 6	7 8 9 0	1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|	 SDES	 |    length	 |	 source	identifier	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  type = ADDR	 |    length	 |    reserved	 | address type	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		       network-layer address			...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  type = ADDR	 |   length = 2	 |    reserved	 | addr. type =	1|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |			    IPv4 address			 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  type = PORT	 |   length = 1	 |	       port		 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  type = PORT	 |   length > 1	 |    reserved	 |    reserved	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |			       port				...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  type = CNAME |    length	 | user	and domain name		...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  type = EMAIL |    length	 | electronic mail address	...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 24]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

 |  type = NAME	 |    length	 | common name of source	...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   type = LOC	 |    length	 | geographic location of site	...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   type = TXT	 |    length	 | text	describing source	...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The SDES option	provides a mapping  between a numeric source identifier	 and
one or more items identifying  the source.[Several attributes were  combined
into one  option so  that the  receiver	does  not have	to perform  multiple
mappings from identifiers to site data structures.]  For those	applications
where the size of a multi-item SDES option would be a concern, multiple	SDES
options	may be	formed with  subsets of	 the items  to be  sent	in  separate
packets.

A bridge uses an identifier  value of zero within  the SDES option to  refer
to itself rather  than content	sources	bridged	 by it.	   For each  content
source,	a bridge forwards  the SDES information	 received from that  source,
but changes the	SDES source identifier to the value used in the	CSRC  option
when identifying that content source.  A bridge	that contributes local	data
to outgoing packets  should select  another non-zero  source identifier	 for
that traffic and send CSRC and SDES options for	it.

Translators do not modify or insert SDES  options.  The	end system  performs
the same  mapping  it  uses  to	 identify  the	content	 sources  (that	 is,
the combination	of  network source,  synchronization source  and the  source
identifier within this SDES option) to	identify a particular source.	SDES
information is	specific to  a particular  channel, unless  a profile  or  a
higher-layer control protocol defines that all packets with the	same  source
identifier (network and	 transport-level source	addresses  and the  optional
SSRC value)  from a  set of  channels defined  by the  control protocol	 are
described by the same SDES.

Currently, the items listed in	Table 2	are defined.   Each has	a  structure
similar	to that	of RTCP	and RTP	 options, that is, a type field	followed  by
a length field,	measured  in multiples of  four	octets.	  No final bit	(see
Section	5.2) is	needed since  the overall length is known.   Text items	 are
encoded	according to  the rules	in  Section 4.	 All of	 the SDES items	 are
optional; however, if quality-of-service monitoring is to be used, one	ADDR
item and the PORT item are mandatory, as described for the QOS option.	Only
the TXT	item is	expected to change during the duration of a session.  Option
types 128 through 255 are  reserved for	private	or experimental	 extensions.
Items are padded with  the binary value	 zero to the  next multiple of	four
octets.	 Each item may appear only once	unless otherwise noted.

A more detailed	description of the content of some of these items follows:


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 25]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993



	  type	 value	description
	  ADDR	 1	network	address	of source
	  PORT	 2	source port
	  CNAME	 4	canonical user and host	identifier,
			e.g., ``doe@sleepy.megacorp.com'' or
			``sleepy.megacorp.com''
	  EMAIL	 5	user's electronic mail address,
			e.g., ``John.Doe@megacorp.com''
	  NAME	 6	common name describing the source,
			e.g.,``John Doe, Bit Recycler, Megacorp''
	  LOC	 8	geographic user	location,
			e.g., ``Rm.  2A244, Murray Hill, NJ''
	  TXT	 16	text describing	the source,
			e.g., ``out for	lunch''


		      Table 2:	Summary	of SDES	items

ADDR: This item	 contains the network  address of the  source, for  example,
    the	IP version  4 address or an NSAP.  The address is carried in  binary
    form,  not as  ``dotted decimal''  or similar  human-readable form.	   A
    source  may	send  several  network	addresses,  but	only  one  for	each
    address type  value.  Address  types are identified	 by the	Domain	Name
    Service Resource Record (RR)  type,	as specified in	the current  edition
    of the Assigned Numbers RFC.

PORT: If the  length field is one, the	transport selector, such as the	 UDP
    port number, is carried as	octets three and four in the first and	only
    word of  the item.	 If  the length	field  is greater  than	one,  octets
    three and  four are	 zero and the  transport selector  appears in  words
    two	and  following of  this	item,  in network byte	order.	 The  figure
    shows the use  of the PORT item  for the TCP and  UDP protocols.   There
    must  be no	 more than  one	PORT  item  in an  SDES	option.	   The	PORT
    item  should immediately  precede  any ADDR	 items.[Multiple  concurrent
    transport  addresses  are not  meaningful.	   The	ordering  simplifies
    processing at  the receiver,  as the  consecutive octet  string of	PORT
    followed by	the first ADDR can be used as a	globally  unique identifier.
    The	transport protocol does	 not need to be	identified, as the  receiver
    will only see one type of transport	protocol for a session.]

CNAME: The CNAME item must have	the format ``user@host'' or  ``host'', where
    ``host'' is	the fully qualified  domain name of the	host from which	 the
    real-time data  originates,	formatted according  to	the rules  specified
    in RFC  1034,  RFC 1035  and Section  2.1 of  RFC 1123.    The  ``host''
    form  may be  used if  a user  name	 is not	 available, for	 example  on
    single-user	systems.  The  user name should	be in a	form that a  program
    such as  ``finger''	or  ``talk'' could use,	 i.e., it  typically is	 the
    login name	rather than  the ``real	 life''	name.	Note  that the	host
    name is not	necessarily identical to the electronic	mail address  of the


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 26]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

    participant.  The latter is	provided through the EMAIL item.

LOC: Depending	on  the	  application,	different  degrees  of	detail	 are
    appropriate	 for this  item.    For	conference  applications,  a  string
    like  ``Murray Hill,  New  Jersey''	may  be	sufficient,  while,  for  an
    active badge system,  strings like ``Room 2A244,  AT&T BL MH'' might  be
    appropriate.  The degree of	detail is left to the  implementation and/or
    user, but format and content may be	prescribed by a	profile.





6.3 BYE: Goodbye


 0		     1			 2		     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|	BYE	| length = 1	|   content source identifier	|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The BYE	option indicates that a	particular session participant is no  longer
active.	 A bridge sends	BYE options with a (non-zero) content source  value.
An identifier  value of	 zero indicates	 that the  source indicated  by	 the
synchronization	source	(SSRC) option  and transport  address is  no  longer
active.	 If a  bridge shuts down, it should  first send	BYE options for	 all
content	sources	it  handles, followed  by a  BYE option	 with an  identifier
value of zero.	 Each  RTCP message can	 contain one or	 more BYE  messages.
Multiple identifiers  in a  single  BYE	option	are  not allowed,  to  avoid
ambiguities between the	special	value of zero and any necessary	padding.



6.4 QOS: Quality of service measurement


  0		      1			  2		      3
  0 1 2	3 4 5 6	7 8 9 0	1 2 3 4	5 6 7 8	9 0 1 2	3 4 5 6	7 8 9 0	1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|	 QOS	 |    length	 |    reserved	 |    reserved	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |			 packets expected			 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |			 packets received			 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    minimum delay (seconds)	 |    minimum delay (fraction)	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    maximum delay (seconds)	 |    maximum delay (fraction)	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    average delay (seconds)	 |    average delay (fraction)	 |


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 27]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  type = PORT	 |    length	 |   transport address		...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  type = ADDR	 |    length	 |    reserved	 | address type	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		       network-layer address			...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The QOS	 option	 conveys  statistics  of  a  single  synchronization  source
belonging to the channel  identified by	the  multicast address,	 destination
port and channel identifier.   The synchronization  source is identified  by
appending the first of the ADDR	items  together	with the PORT item from	 the
SDES option.   These SDES  items are appended  directly	to the	fixed-length
part of	the QOS	option,	with PORT preceding ADDR. For a	description of these
items, see the SDES option.

If the QOS option is used  in reverse control packets, the destination	port
number identifies the channel, along with the channel identifier.  For	that
reason,	every  multicast group	should be  associated with  a unique  source
port.

The other fields of the	option	contain	the number of packets received,	 the
number of packets  expected, the minimum  delay, the  maximum delay and	 the
average	delay.	The expected number of packets may be computed according  to
the algorithm in Section A.5.  The delay measures are in units of 1/65536 of
a second, that is,  with the same resolution as	 the timestamp in the  fixed
RTP header.

A single RTCP packet  may contain several QOS  options.	 It  is	left to	 the
implementor to decide how  often to transmit QOS  options and which  sources
are to be included.




7 Security Considerations


Without	the  use of  the  security options  described  in section  5.4,	 RTP
suffers	from the same security deficiencies as the underlying protocols, for
example, the ability of	 an impostor to	fake  source or	destination  network
addresses, or to change	header or  payload without detection.  For  example,
the SDES fields	may be used to impersonate another participant.

IP multicast provides no direct	means for a sender to know all the receivers
of the	data sent.    RTP  options  make it  easy  for all  participants  in
a session  to identify	themselves;  if	deemed	important for  a  particular
application, it	 is the	 responsibility	of  the	application  writer to	make
listening without identification difficult.   It  should be noted,  however,
that privacy of	the payload can	generally be assured only by encryption.


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 28]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

The periodic transmission of session messages may make it possible to detect
denial-of-service attacks, as the receiver  can	detect the absence of  these
expected messages.

Unlike for other  data,	ciphertext-only	 attacks may be	 more _________	 for
compressed audio  and video  sources.	Such  data is  very close  to  white
noise, making  statistics-based	ciphertext-only	 attacks  difficult.	Even
without	message	 integrity  check  options,  it	 may  be  difficult  for  an
attacker to  detect  automatically when	 he  or	 she has  found	 the  secret
cryptographic key  since  the  bit  pattern  after  correct  decryption	 may
not look  significantly	different  from	one  decrypted with  the wrong	key.
However, the session information is  more or less constant and	predictable,
allowing known-plaintext  attacks.    Chosen-plaintext	attacks	 appear,  in
general, to be difficult.

The integrity of the timestamp in the  fixed RTP header	can be protected  by
the message integrity options.	If  clocks are known to	be synchronized,  an
attacker only has a very limited time window of	maybe a	few seconds every 18
hours to replay	recorded RTP without detection by the receiver.

Key  distribution  and	 certificates  are   outside  the   scope  of	this
document.



8 RTP over Network and Transport Protocols


This section  describes	 issues	 specific to  carrying	RTP  packets  within
particular network and transport protocols.


8.1 Defaults


The following rules apply unless superseded by protocol-specific subsections
in this	section.  The rules apply to both forward and reverse RTP packets.

RTP packets contain no length field or other delineation, so that a  framing
mechanism is  needed  if  they	are carried  in	 underlying  protocols	that
provide	the  abstraction of  a continuous  bit stream  rather than  messages
(packets).  TCP	is an  example of such a protocol.   Framing is	also  needed
if the underlying  protocol may	contain	 padding so that  the extent of	 the
RTP payload cannot  be determined.    For these	 cases,	each  RTP packet  is
prefixed by a 32-bit framing field  containing the length of the RTP  packet
measured in octets,  not including  the	framing	 field itself.	  If an	 RTP
packet traverses a path	over a mixture of octet-stream and  message-oriented
protocols, each	RTP-level bridge between these protocols is responsible	 for
adding and removing the	framing	field.

A profile may determine	that this framing method is to be used even when RTP


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 29]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

is carried in protocols	that do	 provide framing in order to allow  carrying
several	RTP packets in	one lower-layer	protocol  data unit,  such as a	 UDP
packet.	  Carrying several RTP	packets	in one	network	or transport  packet
reduces	header overhead	and  may simplify synchronization between  different
streams.



8.2 ST-II


When used in conjunction  with RTP, ST-II [11]	service	access ports  (SAPs)
have a length of 16  bits.  The	 next protocol field (``NextPCol'',  Section
4.2.2.10 in RFC	1190) is used to distinguish two encapsulations	of RTP	over
ST-II. The first uses NextPCol value TBD and directly places the RTP  packet
into the ST-II data area.  If NextPCol value TBD is used, the RTP  header is
preceded by a 32-bit  header shown below.   The	 octet count determines	 the
number of octets  in the  RTP header  and payload to  be checksummed.	 The
16-bit checksum	uses the TCP and UDP checksum algorithm.


  0		      1			  2		      3
  0 1 2	3 4 5 6	7 8 9 0	1 2 3 4	5 6 7 8	9 0 1 2	3 4 5 6	7 8 9 0	1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | count of octets to be checked |	     check sum		 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |	 RTP packet (fixed header, options and payload)		...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


A Implementation Notes


We describe aspects of the receiver  implementation in this section.   There
may be other implementation methods that are faster in particular  operating
environments or	have other advantages.	 These implementation notes are	 for
informational purposes only.

The  following	definitions  are  used	for  all  examples;   the  structure
definitions are	valid for 32-bit big-endian architectures only.	 Bit  fields
are assumed to be packed tightly, with no additional padding.



#include <sys/types.h>

typedef	double CLOCK_t;

typedef	enum {
  RTP_CSRC   = 0,
  RTP_SSRC   = 1,
  RTP_SDST   = 2,

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 30]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

  RTP_BOS    = 3,
  RTP_ENC    = 8,
  RTP_MIC    = 9,
  RTP_MICA   = 10,
  RTP_MICK   = 11,
  RTP_MICS   = 12,
  RTP_FMT    = 32,
  RTP_SDES   = 34,
  RTP_BYE    = 35,
  RTP_QOS    = 36
} rtp_option_t;

typedef	struct {
  unsigned int ver:2;	   /* version number */
  unsigned int channel:6;  /* channel id */
  unsigned int o:1;	   /* option present */
  unsigned int s:1;	   /* sync bit */
  unsigned int format:6;   /* content type */
  u_short seq;		   /* sequence number */
  u_long  ts;		   /* time stamp */
} rtp_hdr_t;

typedef	union {
  struct {
    int	final:1;	   /* final option */
    int	type:7;		   /* option type */
    u_char length;	   /* length, including	type/length */
    short id[1];
  } csrc;
  /* ... */
} rtp_t;



A.1 Timestamp Recovery


For some applications  it is  useful to	 have the  receiver reconstruct	 the
sender's high-order  bits of  the  NTP timestamp  from the  received  32-bit
RTP timestamp.	  The following	 code uses  double-precision floating  point
numbers	for  whole numbers  with a  48-bit range.    Other type	 definitions
of CLOCK_t may be  appropriate for different  operating	environments,  e.g.,
64-bit architectures  or systems  with slow  floating point  support.	 The
routine	applies	to any clock frequency,	not just the RTP value of 65,536 Hz,
and any	clock starting	point.	It  will reconstruct the correct  high-order
bits as	long as	the local clock	 now is	within one half	of wrap-around	time
of the 32-bit timestamp, e.g., approximately 9.2 hours for RTP timestamps.



#include <math.h>


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 31]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

#define	MOD32bit 4294967296.
#define	MAX31bit 0x7fffffff

CLOCK_t	clock_extend(ts, now)
u_long ts;    /* in: timestamp,	low-order 32 bits */
CLOCK_t	now;  /* in: current local time	*/
{
  u_long high, low;   /* high and low order bits of 48-bit clock */

  low  = fmod(now, MOD32bit);
  high = now / MOD32bit;

  if (low > ts)	{
    if (low - ts > MAX31bit) high++;
  }
  else {
    if (ts - low > MAX31bit) high--;
  }
  return high *	MOD32bit + ts;
} /* extend_timestamp */




Using the full timestamp internally has	the advantage that the remainder  of
the receiver code does not have	to be concerned	with modulo arithmetic.	 The
current	local time  does not  have to be  derived directly  from the  system
clock for every	packet;	a clock	 based on samples, e.g., incremented by	 the
nominal	audio  frame duration,	is sufficient.	  The whole  seconds  within
NTP time stamps	can  be	obtained by  adding 2208988800 to  the value of	 the
standard Unix  clock (generated,  for example,	by  the	gettimeofday  system
call), which starts from the  year 1970.  For  the RTP time stamp, only	 the
least significant 16 bits of the second	are used.


A.2 Detecting the Beginning of a Synchronization Unit


RTP packets contain a bit flag indicating the end of a synchronization unit.
The following code  fragment determines,  based	 on sequence numbers,  if  a
packet is the  beginning of a  synchronization unit.   It  assumes that	 the
packet header has been converted to host byte order.


static u_long seq_eos;
rtp_hdr_t *h;
static int flag;

if (h->s) {
  flag	  = 1;
  seq_eos = h->seq;
}

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 32]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

/* handle wrap-around of sequence number */
else if	(flag && (h->seq - seq_eos < 32768)) {
  flag = 0;
  /* handle beginning of synchronization unit */
}



A.3 Demultiplexing and Locating	the Synchronization Source


The combination	 of  destination  address,   destination  port	and  channel
identifier determines the channel.  For	each channel, the receiver maintains
a list of all sources, content and synchronization sources alike, in a table
or other suitable data structure.   Synchronization sources are	stored	with
a content source value of  zero.  When an  RTP packet arrives, the  receiver
determines its network	source address and  port (from information  returned
by the operating system), synchronization  source (SSRC	option)	and  content
source(s) (CSRC	 option).    To	locate	the  table entry  containing  timing
information, mapping from content descriptor  to actual	encoding, etc.,	 the
receiver sets the content source to zero and locates a table entry based  on
the triple (transport source address, and synchronization source identifier,
0).

The receiver identifies	 the contributors to  the packet  (for example,	 the
speaker	who is	heard in  the packet) through  the list	 of content  sources
carried	in the CSRC option.   To locate	the  table entry, it matches on	 the
triple (network	address	and port, synchronization source identifier, content
source).

Note that  since  network  addresses  are  only	 generated  locally  at	 the
receiver, the receiver can choose whatever format seems	most appropriate for
matching.  For example,	a Berkeley Unix-based system may use struct sockaddr
data types if it expects network sources with non-IP addresses.


A.4 Parsing RTP	Options


The following  code  segment  walks  through  the  RTP options,	  preventing
infinite loops due to zero and invalid length fields.  Structure definitions
are valid for big-endian architectures only.


u_long len;	  /* length of RTP packet in bytes */
u_long *pt;	  /* pointer */
rtp_hdr_t *h;	  /* fixed header */
rtp_t *r;	  /* options */

if (h->o) {
  for (pt = (u_long *)(h+1);; pt += r->csrc.length) {


H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 33]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

    r =	(rtp_t *)pt;

    /* invalid length field */
    if ((char *)pt - (char *)h > len ||	r->csrc.length == 0) return -1;

    switch(r->csrc.type) {
      case RTP_BYE:
	/* handle BYE option */
	break;
      case RTP_CSRC:
	/* handle CSRC option */
	break;

	/* ... */

      default:
	/* undefined option */
	break;
    }
    if (r->csrc.final) break;
  }
}



A.5 Determining	the Expected Number of RTP Packets


The number of packets expected can  be computed	by the receiver	by  tracking
the first  sequence  number  received  (seq0),	 the  last  sequence  number
received, seq, and the number of complete sequence number cycles:


expected = cycles * 65536 + seq	- seq0 + 1;


The cycle count	is updated for each packet, where seq_prior is the  sequence
number of the prior packet:



unsigned long seq, seq_prior;

if (seq	- seq_prior > 65536)
  cycle++;
else if	(seq - seq_prior > 32768)
  cycle--;

seq_prior = seq;




H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 34]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

Acknowledgments


This  memorandum  is  based  on	 discussions  within  the  IETF	 audio-video
transport working group	chaired	by Stephen Casner.  The	current	protocol has
its origins in	the Network  Voice Protocol  and the  Packet Video  Protocol
(Danny Cohen  and  Randy Cole)	and  the  protocol implemented	by  the	 vat
application (Van  Jacobson and	Steve McCanne).	   Stuart Stubblebine  (ISI)
helped with the	security aspects of RTP. Ron Frederic (Xerox PARC)  provided
extensive editorial assistance.



B Addresses of Authors


Stephen	Casner
USC/Information	Sciences Institute
4676 Admiralty Way
Marina del Rey,	CA 90292-6695
telephone:  +1 310 822 1511 (extension 153)
electronic mail:  casner@isi.edu


Henning	Schulzrinne
AT&T Bell Laboratories
MH 2A244
600 Mountain Avenue
Murray Hill, NJ	07974-0636
telephone:  +1 908 582 2262
facsimile:  +1 908 582 5809
electronic mail:  hgs@research.att.com



References


 [1] D.	E.  Comer, _______________  ____ ______, vol.  1. Englewood  Cliffs,
     New Jersey:  Prentice Hall, 1991.

 [2] J.	 Postel, ``Internet protocol,''	 Network Working  Group	Request	 for
     Comments RFC 791, Information Sciences Institute, Sept. 1981.

 [3] International  Standards	Organization,  ``ISO/IEC  DIS	10646-1:1993
     information technology -- universal multiple-octet	coded  character set
     (UCS) -- part I: Architecture and basic multilingual plane,'' 1993.

 [4] The  Unicode Consortium,  ___ _______  ________.  New York,  New  York:
     Addison-Wesley, 1991.

 [5] D.	 L. Mills,  ``Network time  protocol (version  3) --  specification,

H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 35]


INTERNET-DRAFT		draft-ietf-avt-rtp-03.txt	  September 15,	1993

     implementation  and  analysis,''  Network	Working	 Group	Request	 for
     Comments RFC 1305,	University of Delaware,	Mar. 1992.

 [6] S.	 Kent,	``Understanding	 the  Internet	certification system,''	  in
     ___________  __ ___  _____________	__________  __________ ______,	(San
     Francisco,	California),  pp. BAB--1 -- BAB--10, Internet Society,	Aug.
     1993.

 [7] D.	Balenson, ``Privacy enhancement	for internet electronic	mail:	Part
     III:  Algorithms,	modes,	and  identifiers,''  Network  Working  Group
     Request for Comments RFC 1423, IETF, Feb. 1993.

 [8] V.	 L. Voydock  and S.  T.	Kent,  ``Security  mechanisms in  high-level
     network  protocols,'' ___	_________ _______,  vol. 15,  pp.  135--171,
     June 1983.

 [9] J.	Kaliski,  Burton S., ``The  MD2	message-digest algorithm,''  Network
     Working Group  Request for	 Comments RFC 1319,  RSA Laboratories,	Apr.
     1992.

[10] R.	Rivest,	``The MD5 message-digest algorithm,'' Network  Working Group
     Request for Comments RFC 1321, IETF, Apr. 1992.

[11] C.	 Topolcic, S.  Casner,	C. Lynn,  Jr.,	P.  Park, and  K.  Schroder,
     ``Experimental internet  stream protocol, version 2 (ST-II),''  Network
     Working  Group  Request   for  Comments  RFC  1190,  BBN  Systems	 and
     Technologies, Oct.	1990.


























H. Schulzrinne/S. Casner	     Expires 11/01/93		   [Page 36]