home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mmusic-sdp-02.txt < prev    next >
Text File  |  1996-11-27  |  57KB  |  1,852 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8. Internet Engineering Task Force                      MMUSIC WG
  9. INTERNET-DRAFT                      Mark Handley/Van Jacobson
  10. draft-ietf-mmusic-sdp-02.txt                       ISI/LBNL
  11.                                   21st Nov 1996
  12.                              Expires: 21st May 1997
  13.  
  14.  
  15.            SDP: Session Description Protocol
  16.  
  17.  
  18.  
  19. Status of this Memo
  20.  
  21. This document is an Internet-Draft.  Internet-Drafts are  working  docu-
  22. ments  of the Internet Engineering Task Force (IETF), its areas, and its
  23. working groups.     Note that other  groups  may  also  distribute     working
  24. documents as Internet-Drafts.
  25.  
  26. Internet-Drafts are draft documents valid for a maximum     of  six  months
  27. and  may  be  updated,    replaced, or obsoleted by other documents at any
  28. time.  It is inappropriate to use Internet-Drafts as reference    material
  29. or to cite them other than as ``work in progress.''
  30.  
  31. To learn the current status of    any  Internet-Draft,  please  check  the
  32. ``1id-abstracts.txt''  listing    contained  in the Internet-Drafts Shadow
  33. Directories   on   ftp.is.co.za      (Africa),   nic.nordu.net    (Europe),
  34. munnari.oz.au    (Pacific  Rim),     ds.internic.net  (US  East  Coast),  or
  35. ftp.isi.edu (US West Coast).
  36.  
  37. Distribution of this document is unlimited.
  38.  
  39.  
  40.                 Abstract
  41.  
  42.  
  43.      This document defined the Session Description  Protocol,  SDP.
  44.      SDP  is  intended    for  describing multimedia sessions for the
  45.      purposes of  session  announcement,  session  invitation,    and
  46.      other forms of session initiation.
  47.  
  48.  
  49. This document is a product of the Multiparty Multimedia Session     Control
  50. (MMUSIC) working group of the Internet Engineering Task Force.    Comments
  51. are solicited and should be addressed to  the  working    group's     mailing
  52. list at confctrl@isi.edu and/or the authors.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Handley/Jacobson                            [Page 1]
  59.  
  60. INTERNET-DRAFT                           21st Nov 1996
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65. On the Internet multicast backbone (Mbone), a session directory tool  is
  66. used  to advertise multimedia conferences and communicate the conference
  67. addresses and conference tool-specific information necessary for  parti-
  68. cipation.  This document defines a session description protocol for this
  69. purpose, and for general real-time multimedia session  description  pur-
  70. poses.    This draft does not describe multicast address allocation or the
  71. distribution of SDP messages in detail.     These are described  in  accom-
  72. panying drafts.
  73.  
  74. 2.  Background
  75.  
  76. The Mbone is the part of the internet that supports  IP     multicast,  and
  77. thus  permits  efficient  many-to-many communication.  It is used exten-
  78. sively for multimedia conferencing.  Such conferences usually  have  the
  79. property  that tight coordination of conference membership is not neces-
  80. sary; to receive a conference, a user at an Mbone site only has to  know
  81. the  conference's  multicast  group  address  and  the UDP ports for the
  82. conference data streams.
  83.  
  84. Session directories assist the advertisement of conference sessions  and
  85. communicate  the  relevant  conference    setup information to prospective
  86. participants.
  87.  
  88. This document defines a session description protocol  that  is    used  to
  89. define multimedia sessions.  It is also an attempt to provide guidelines
  90. to the writers of such announcement tools  to  protect    the  Mbone  from
  91. misuse    and to preserve the inherent scalability of the original LBNL sd
  92. session directory program whilst enhancing its functionality.
  93.  
  94. We have also attempted to enhance the generality of SDP so that     it  can
  95. be  used for a wider range of network environments and applications than
  96. just multicast session directories.
  97.  
  98.  
  99. 3.  Glossary of Terms
  100.  
  101. The following terms are used in this document, and have specific meaning
  102. within the context of this document.
  103.  
  104. Conference
  105.     A multimedia conference is a set of two or more communicating  users
  106.     along with the software they are using to communicate.
  107.  
  108. Session
  109.     A multimedia session is a set a multimedia senders and receivers and
  110.     the     data  streams    flowing from senders to receivers.  A multimedia
  111.  
  112.  
  113.  
  114. Handley/Jacobson                            [Page 2]
  115.  
  116. INTERNET-DRAFT                           21st Nov 1996
  117.  
  118.  
  119.     conference is an example of a multimedia session.
  120.  
  121. Session Advertisement
  122.     See session announcement.
  123.  
  124. Session Announcement
  125.     A session announcement is a mechanism by which a session description
  126.     is    conveyed  to  users  is     a pro-active fashion, i.e., the session
  127.     description was not explicitly requested by the user.
  128.  
  129. Session Description
  130.     A well defined format for conveying sufficient information    to  dis-
  131.     cover and participate in a multimedia session.
  132.  
  133. 4.  SDP Usage
  134.  
  135. 4.1.  Multicast Announcements
  136.  
  137. SDP is a session description protocol for multimedia sessions.    Normally
  138. it  is    used  by  an  SDP  client that announces a conference session by
  139. periodically multicasting an announcement packet on a well known  multi-
  140. cast address and port.    With the advent of administrative scoping in the
  141. Mbone, it is likely that session directory clients will need to be  able
  142. to listen for such announcements on multiple addresses.     This multicast-
  143. ing of announcements is performed by the Session  Announcement    Protocol
  144. (SAP).
  145.  
  146. SAP packets are UDP packets with the following format:
  147.  
  148.      0             31
  149.      |--------------------|
  150.      | SAP header          |
  151.      |--------------------|
  152.      | text payload          |
  153.      |/\/\/\/\/\/\/\/\/\/\|
  154.  
  155.  
  156. The  header  is     the  Session  Announcement  Protocol  header.     SAP  is
  157. described in more detail in a companion draft [4]
  158.  
  159. The text payload is an SDP session description,     as  described    in  this
  160. draft.     The  text  payload should be no greater than 1 Kbyte in length.
  161. If announced by SAP, only one session announcement  is    permitted  in  a
  162. single packet.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Handley/Jacobson                            [Page 3]
  171.  
  172. INTERNET-DRAFT                           21st Nov 1996
  173.  
  174.  
  175. 4.2.  Email and WWW Announcements
  176.  
  177. For both email and WWW distribution, the use of the MIME content type
  178. ``application/x-sdp''  is  currently  suggested.    This   enables   the
  179. automatic  launching  of applications from the WWW client or mail reader
  180. in a standard manner.
  181.  
  182. Note that announcements of multicast sessions made only via email or the
  183. World  Wide  Web  (WWW)     do not have the property that the receiver of a
  184. session announcement can necessarily receive the session,  nor    do  they
  185. allow scalable dynamic multicast address allocation.
  186.  
  187.  
  188. 5.  Requirements and Recommendations
  189.  
  190.  
  191. The purpose of SDP is to convey information about media streams in  mul-
  192. timedia     sessions  to  allow  the recipients of a session description to
  193. participate in the session.  SDP is primarily intended    for  use  in  an
  194. internetwork,  although     it is sufficiently general that it can describe
  195. conferences in other network environments.
  196.  
  197. A multimedia session, for these purposes, is defined as a set  of  media
  198. streams     that  exist  for  some     duration of time.  Media streams can be
  199. many-to-many.  The times during which the session is active need not  be
  200. continuous.
  201.  
  202. Thus far, multicast based sessions on the internet  have  differed  from
  203. many  other  forms  of conferencing in that anyone receiving the traffic
  204. can join the session (unless the session traffic is encrypted).     In such
  205. an  environment, SDP serves two primary purposes.  It is a means to com-
  206. municate the existence of a session, and is a means to convey sufficient
  207. information  to     enable     joining and participating in the session.  In a
  208. unicast environment, only the latter purpose is likely to be relevant.
  209.  
  210. Thus SDP includes:
  211.  
  212. +   Session name and purpose
  213.  
  214. +   Time(s) the session is active
  215.  
  216. +   The media comprising the session
  217.  
  218. +   Information to receive those media (addresses, ports, formats and so
  219.     on)
  220.  
  221. As resources necessary to participate in a session may be limited,  some
  222. additional information may also be desirable:
  223.  
  224.  
  225.  
  226. Handley/Jacobson                            [Page 4]
  227.  
  228. INTERNET-DRAFT                           21st Nov 1996
  229.  
  230.  
  231. +   Information about the bandwidth to be used by the conference
  232.  
  233. +   Contact information for the person responsible for the session
  234.  
  235. In general, SDP must convey sufficient information to be able to join  a
  236. session (with the possible exception of encryption keys) and to announce
  237. the resources to be used to non-participants that may need to know.
  238.  
  239.  
  240. 5.1.  Media Information
  241.  
  242. SDP includes:
  243.  
  244. +   The type of media (video, audio, etc)
  245.  
  246. +   The transport protocol (RTP/UDP/IP, H.320, etc)
  247.  
  248. +   The format of the media (H.261 video, MPEG video, etc)
  249.  
  250. For an IP multicast session, the following are also conveyed:
  251.  
  252. +   Multicast address for media
  253.  
  254. +   Transport Port for media
  255.  
  256. For an IP unicast session, the following are conveyed:
  257.  
  258. +   Contact address for media
  259.  
  260. +   Transport port for contact address
  261.  
  262. This may or may not be be  the    source    and  destination  of  the  media
  263. stream.
  264.  
  265. Sessions being conveyed over other types of network will have their  own
  266. specific requirements - SDP must be extensible for these.
  267.  
  268.  
  269. 5.2.  Timing Information
  270.  
  271. Sessions may either be bounded or unbounded in    time.    Whether     or  not
  272. they are bounded, they may be only active at specific times.
  273.  
  274. SDP can convey:
  275.  
  276. +    An arbitrary list of start and stop times bounding the session
  277.  
  278. +    For each bound, repeat times such as "every Wednesday at  10am  for
  279.  
  280.  
  281.  
  282. Handley/Jacobson                            [Page 5]
  283.  
  284. INTERNET-DRAFT                           21st Nov 1996
  285.  
  286.  
  287.      one hour"
  288.  
  289. This timing information is globally consistent,     irrespective  of  local
  290. time zone or daylight saving time
  291.  
  292.  
  293. 5.3.  Private Sessions
  294.  
  295.  
  296. It is possible to create both  public  sessions     and  private  sessions.
  297. Private     sessions  will     typically be conveyed by encrypting the session
  298. description to distribute it.  The details of  how  encryption    is  per-
  299. formed    are  dependent on the mechanism used to convey SDP - see [4] for
  300. how this is done for session announcements.
  301.  
  302. If a session announcement is private it is possible to use that     private
  303. announcement  to  convey encryption keys necessary to decode each of the
  304. media in a  conference,     including  enough  information     to  know  which
  305. encryption scheme is used for each media.
  306.  
  307.  
  308. 5.4.  Further Information
  309.  
  310. SDP should convey enough information to decide whether or not to  parti-
  311. cipate    in a session.  It should include additional pointers in the form
  312. of Universal Resources Identifiers (URIs) for
  313.  more information about the session.
  314.  
  315.  
  316. 5.5.  Categorisation
  317.  
  318. When many session descriptions are being distributed by SAP or any other
  319. advertisement  mechanism,  it  may  be desirable to filter announcements
  320. that are of interest from those that are  not.     SDP  should  support  a
  321. categorisation     mechanism   for  sessions  that  is  capable  of  being
  322. automated.
  323.  
  324.  
  325. 5.6.  Internationalization
  326.  
  327. The SDP specification recommends the use of 8-bit ISO  8859-1  character
  328. sets  to  allow     the  extended ASCII characters used by many western and
  329. northern European languages to be represented.    However, there are  many
  330. languages  that     cannot     be  represented in an ISO 8859-1 character set.
  331. SDP should also allow extensions to allow other font types  to    be  used
  332. when required.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Handley/Jacobson                            [Page 6]
  339.  
  340. INTERNET-DRAFT                           21st Nov 1996
  341.  
  342.  
  343. 6.  SDP Specification
  344.  
  345. SDP session descriptions are entirely textual.     The  textual  form,  as
  346. opposed to a binary encoding such as ASN/1 or XDR, was chosen to enhance
  347. portability, to enable a variety of transports to be used (e.g,     session
  348. description  in     a MIME email message) and to allow flexible, text-based
  349. toolkits (e.g., Tcl/Tk ) to be used to generate and to    process     session
  350. descriptions.    However,  since the total bandwidth allocated to all SAP
  351. announcements is strictly limited, the encoding is deliberately compact.
  352. Also,  since  announcements may be transported via very unreliable means
  353. (e.g., email) or damaged by an intermediate caching server, the encoding
  354. was  designed with strict order and formatting rules so that most errors
  355. would result in malformed announcements which could be    detected  easily
  356. and discarded.    This also allows rapid discarding of encrypted announce-
  357. ments for which a receiver does not have the correct key.
  358.  
  359. An SDP session description consists of a number of lines of text of  the
  360. form
  361. <type>=<value>
  362. <type> is always exactly one character and is case-significant.     <value>
  363. is  a structured text string whose format depends on <type>.  Whitespace
  364. is not permitted either side of the `='     sign.    In  general  <value>  is
  365. either    a  number  of  fields delimited by a single space character or a
  366. free format string.
  367.  
  368. Each announcement consists of a session description section followed  by
  369. zero  or  more    `media'     description  sections.     The session description
  370. starts with a `v=' line and continues to the first media description  or
  371. the next session description.  The media description starts with an `m='
  372. line and continues to the next media description or session description.
  373. When SDP is conveyed by SAP, only one session description is allowed per
  374. packet.     When SDP is conveyed by other means, many SDP session    descrip-
  375. tions  may be concatenated together.  Some lines in each description are
  376. required and some are optional but all must appear in exactly the  order
  377. given  here (the fixed order greatly enhances error detection and allows
  378. for a simple parser).  Optional items are marked with a `*'.
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Handley/Jacobson                            [Page 7]
  395.  
  396. INTERNET-DRAFT                           21st Nov 1996
  397.  
  398.  
  399.  
  400.     Session description
  401.         v=  (protocol version)
  402.         o=  (owner/creator and session identifier).
  403.         s=  (session name)
  404.         i=* (session information)
  405.         u=* (URI of description)
  406.         e=* (email address)
  407.         p=* (phone number)
  408.         c=* (connection information - not required if included in all media)
  409.         b=* (bandwidth information)
  410.         One or more time descriptions
  411.         z=* (time zone adjustments)
  412.         k=* (encryption key)
  413.         a=* (zero or more session attribute lines)
  414.         Zero or more media descriptions
  415.  
  416.     Time description
  417.         t=  (time the session is active)
  418.         r=* (zero or more repeat times)
  419.  
  420.     Media description
  421.         m=  (media name and transport address)
  422.         i=* (media title)
  423.         c=* (connection information - optional if included at session-level)
  424.         b=* (bandwidth information)
  425.         k=* (encryption key)
  426.         a=* (zero or more media attribute lines)
  427.  
  428. The set of `type' letters is deliberately small and not intended  to  be
  429. extensible  --    SDP parsers must completely ignore any announcement that
  430. contains a `type' letter that it does not understand.    The  `attribute'
  431. mechanism  (described  below) is the primary means for extending SDP and
  432. tailoring it to particular applications or media.  Some attributes  (the
  433. ones  listed  in this document) have a defined meaning but others may be
  434. added on an application-, media- or session-specific basis.   A     session
  435. directory must ignore any attribute it doesn't understand.
  436.  
  437. The connection (`c=') and attribute (`a=') information    in  the     session
  438. section     applies  to  all the media of that session unless overridden by
  439. connection information or an attribute of the same  name  in  the  media
  440. description.   For instance, in the example below, each media behaves as
  441. if it were given a `recvonly' attribute.
  442.  
  443. An example SDP description is:
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Handley/Jacobson                            [Page 8]
  451.  
  452. INTERNET-DRAFT                           21st Nov 1996
  453.  
  454.  
  455.  
  456.     v=0
  457.     o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
  458.     s=SDP Seminar
  459.     i=A Seminar on the session description protocol
  460.     u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
  461.     e=mjh@isi.edu (Mark Handley)
  462.     c=IN IP4 224.2.17.12/127
  463.     t=2873397496 2873404696
  464.     a=recvonly
  465.     m=audio 3456 RTP/AVP 0
  466.     m=video 2232 RTP/AVP 31
  467.     m=whiteboard 32416 UDP WB
  468.     a=orient:portrait
  469.  
  470.  
  471. Text records such as the session name and information  may  contain  any
  472. printable  8  bit ISO 8859-1 character with the exceptions of 0x0a (new-
  473. line) and 0x0d (carriage return).  Carriage Return  is    prohibited,  and
  474. Newline is used to end a record.
  475.  
  476. Protocol Version
  477.  
  478. v=0
  479.  
  480. The ``v'' field gives the version of the Session  Description  Protocol.
  481. There is no minor version number.
  482.  
  483. Origin
  484.  
  485. o=<username>  <session    id>  <version>    <network  type>     <address  type>
  486. <address>
  487.  
  488.  
  489. The ``o'' field gives the originator of the session (their username  and
  490. the  address  of  the user's host) plus a session id and session version
  491. number.     <username> is the user's login on the originating host,  or  it
  492. is  ``-''  if  the originating host does not support the concept of user
  493. ids.  <username> must not contain spaces.  <session  id>  is  a     numeric
  494. string    such  that  the triple of <username>, <session id> and <address>
  495. form a globally unique identifier for the session.  The method    of  ses-
  496. sion id allocation is up to the creating tool, but it has been suggested
  497. that a Network Time Protocol (NTP) timestamp be used to     ensure     unique-
  498. ness  [1].   <version> is a version number for this announcement.  It is
  499. needed for proxy announcements to detect which of several  announcements
  500. for  the  same session is the most recent.  Again its usage is up to the
  501. creating tool, so long as <version> is increased when a modification  is
  502. made  to the session data.  Again, it is recommended (but not mandatory)
  503.  
  504.  
  505.  
  506. Handley/Jacobson                            [Page 9]
  507.  
  508. INTERNET-DRAFT                           21st Nov 1996
  509.  
  510.  
  511. that an NTP timestamp is used.    <network type> is a text  string  giving
  512. the  type  of  network.     Initially ``IN'' is defined to have the meaning
  513. ``Internet''.  <address type> is a text string giving the  type     of  the
  514. address     that  follows.      Initially  ``IP4''  and  ``IP6''  are defined.
  515. <address> is the globally unique address of the machine from  which  the
  516. session     was  created.     For an address type of IP4, this is the dotted-
  517. decimal representation of the IP version 4 address of the machine.
  518.  
  519.  
  520. Session Name
  521.  
  522. s=<session name>
  523.  
  524. The ``s'' field is the session name.  There must be  one  and  only  one
  525. ``s''  field  per announcement, and it must contain printable ISO 8859-1
  526. characters (but see also the `charset' attribute below).
  527.  
  528. Session and Media Information
  529.  
  530. i=<session description>
  531.  
  532. The ``i'' field is information about the session.  There must be no more
  533. than one session-level ``i'' field per session announcement. Although it
  534. may be omitted, this is discouraged, and user interfaces  for  composing
  535. sessions  should  require  text to be entered.    If it is present it must
  536. contain printable ISO 8859-1 characters     (but  see  also  the  `charset'
  537. attribute below).
  538.  
  539. A single ``i'' field can also be used for  each     media    definition.   In
  540. media  definitions,  ``i''  fields  are     primarily intended for labeling
  541. media streams.    As such, they are most likely to be useful when a single
  542. session     has more than one distinct media stream of the same media type.
  543. An example would be two different whiteboards, one for    slides    and  one
  544. for feedback and questions.
  545.  
  546.  
  547. URI
  548.  
  549. u=<URI>
  550.  
  551.  
  552. +   A URI is a Universal Resource Identifier as used by WWW clients
  553.  
  554. +   The URI should be a pointer     to  additional     information  about  the
  555.     conference
  556.  
  557. +   This field is optional, but if it is present it should be  specified
  558.     before the first media field
  559.  
  560.  
  561.  
  562. Handley/Jacobson                               [Page 10]
  563.  
  564. INTERNET-DRAFT                           21st Nov 1996
  565.  
  566.  
  567. +   No more than one URI field is allowed per session description
  568.  
  569.  
  570. Email Address and Phone Number
  571.  
  572. e=<email address>
  573. p=<phone number>
  574.  
  575.  
  576. +   These specify contact information for the person responsible for the
  577.     conference.      This    is  not necessarily the same person that created
  578.     the conference announcement.
  579.  
  580. +   Either an email field or a phone field  must  be  specified.   Addi-
  581.     tional email and phone fields are allowed.
  582.  
  583. +   If these are present, they should  be  specified  before  the  first
  584.     media field.
  585.  
  586. +   More than one email or phone  field     can  be  given     for  a     session
  587.     description.
  588.  
  589. +   Phone numbers should be given in the conventional international for-
  590.     mat - preceded by a ``+'' and the international country code.  There
  591.     must be a space or a hyphen (``-'') between the country code and the
  592.     rest  of  the phone number.     Spaces and hyphens may be used to split
  593.     up a phone field to aid readability if desired. For example:
  594.  
  595.     p=+44-171-380-7777    or    p=+1 617 253 6011
  596.  
  597. +   Both email addresses and phone numbers can    have  an  optional  free
  598.     text  string  associated  with them, normally giving the name of the
  599.     person who may be contacted.  This should be enclosed in parenthesis
  600.     if it is present.  For example:
  601.  
  602.     e=mjh@isi.edu (Mark Handley)
  603.  
  604.     The alternative RFC822 name quoting convention is also  allowed  for
  605.     both email addresses and phone numbers.  For example,
  606.  
  607.     e=Mark Handley <mjh@isi.edu>
  608.  
  609.     The free text string should be in an IS0-8859-1  character    set,  or
  610.     alternatively  in  unicode UTF-7 encoding if the appropriate charset
  611.     session-level attribute is set.
  612.  
  613. Connection Data
  614.  
  615.  
  616.  
  617.  
  618. Handley/Jacobson                               [Page 11]
  619.  
  620. INTERNET-DRAFT                           21st Nov 1996
  621.  
  622.  
  623. c=<network type> <address type> <connection address>
  624.  
  625. The ``c'' field contains connection data.
  626.  
  627. The first sub-field is the network type, which is a text  string  giving
  628. the  type  of  network.     Initially ``IN'' is defined to have the meaning
  629. ``Internet''
  630.  
  631. The second sub-field is the address type.  This allows SDP  to    be  used
  632. for sessions that are not IP based.  Currently only IP4 is defined.
  633.  
  634. The third sub-field is the  connection    address.   Optional  extra  sub-
  635. fields    may be added after the connection address depending on the value
  636. of the <address type> field.
  637.  
  638. For IP4 addresses, the connection address is defined as follows:
  639.  
  640. +   Typically the connection address will  be  a  class-D  IP  multicast
  641.     group address.  If the conference is not multicast, then the connec-
  642.     tion address contains the unicast IP address of  the  expected  data
  643.     source or data relay or data sink as determined by additional attri-
  644.     bute fields.  It is not expected  that  unicast  addresses    will  be
  645.     given  in  a session description that is communicated by a multicast
  646.     announcement, though this is not prohibited.
  647.  
  648.  
  649. +   Conferences using an IP multicast connection address must also  have
  650.     a  time  to     live  (TTL)  value present in addition to the multicast
  651.     address.  The TTL defines the scope     with  which  multicast     packets
  652.     sent  in  this  conference should be sent. TTL values must be in the
  653.     range 0-255.  The Mbone usage  guidelines  (currently  available  at
  654.     ftp://ftp.isi.edu/mbone/faq.txt)  define  several  standard settings
  655.     for TTL:
  656.  
  657.  
  658.         local net:          1
  659.         site:         15
  660.         region:         63
  661.         world:        127
  662.  
  663.     Other settings may have local meaning (e.g., 31 for all sites within
  664.     an organization).
  665.  
  666.     The TTL for the session is appended to the address using a slash  as
  667.     a separator.  An example is:
  668.  
  669.         c=IN IP4 224.2.1.1/127
  670.  
  671.  
  672.  
  673.  
  674. Handley/Jacobson                               [Page 12]
  675.  
  676. INTERNET-DRAFT                           21st Nov 1996
  677.  
  678.  
  679.     Hierarchical or layered encoding schemes are data streams where  the
  680.     encoding  from  a  single  media  source  is  split into a number of
  681.     layers.  The receiver can choose  the  desired  quality  (and  hence
  682.     bandwidth)    by  only  subscribing to a subset of these layers.  Such
  683.     layered encodings are normally  transmitted     in  multiple  multicast
  684.     groups  to    allow  multicast pruning.  This technique keeps unwanted
  685.     traffic from sites only requiring certain levels of     the  hierarchy.
  686.     For     applications  requiring multiple multicast groups, we allow the
  687.     following notation to be used for the connection address:
  688.  
  689.  
  690.         <base multicast address>/<ttl>/<number of addresses>
  691.  
  692.     If the number of addresses is not given it is  assumed  to    be  one.
  693.     Multicast addresses so assigned are contiguously allocated above the
  694.     base address, so that, for example:
  695.  
  696.         c=IN IP4 224.2.1.1/127/3
  697.  
  698.     would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to
  699.     be used at a ttl of 127.
  700.  
  701.     It is illegal for the slash notation described above to be used  for
  702.     IP unicast addresses.
  703.  
  704.     A session announcement must contain one ``c'' field     in  each  media
  705.     description     (see  below) or a ``c'' field at the session-level.  It
  706.     may contain a session-level ``c'' field  and  one  additional  ``c''
  707.     field  per    media  description,  in     which case the per-media values
  708.     override the session-level settings for the relevant media.
  709.  
  710. Bandwidth
  711.  
  712. b=<modifier>:<bandwidth-value>
  713.  
  714.  
  715. +   This specifies the proposed bandwidth to be used by the  session  or
  716.     media, and is optional.
  717.  
  718. +   <bandwidth-value>  is in kilobits per second
  719.  
  720. +   <modifier>    is an single alphanumeric word giving the meaning of the
  721.     bandwidth figure.
  722.  
  723. +   Two modifiers are initially defined:
  724.  
  725. CT    Conference Total: An implicit maximum bandwidth is associated with
  726.       each   TTL   on    the  Mbone  or    within    a  particular  multicast
  727.  
  728.  
  729.  
  730. Handley/Jacobson                               [Page 13]
  731.  
  732. INTERNET-DRAFT                           21st Nov 1996
  733.  
  734.  
  735.       administrative scope region (the Mbone bandwidth    vs.  TTL  limits
  736.       are  given  in  the  MBone FAQ).    If the bandwidth of a session or
  737.       media in a session is different from the bandwidth  implicit  from
  738.       the  scope,  a  `b=CT:...' line should be supplied for the session
  739.       giving the proposed upper limit to the bandwidth used.   The  pri-
  740.       mary  purpose of this is to give an approximate idea as to whether
  741.       two or more conferences can co-exist simultaneously.
  742.  
  743. AS    Application Specific Maximum: The bandwidth is interpreted  to  be
  744.       application  specific,  i.e., will be the application's concept of
  745.       maximum bandwidth.  Normally this will coincide with what     is  set
  746.       on the application's ``maximum bandwidth'' control if applicable.
  747.  
  748.     Note that CT gives a total bandwidth figure for all the media at all
  749.     sites.   AS     gives a bandwidth figure for a single media at a single
  750.     site, although there may be many sites sending simultaneously.
  751.  
  752. +   Extension Mechanism: Tool writers can define experimental  bandwidth
  753.     modifiers by prefixing their modifier with ``X-''.    For example:
  754.  
  755.     b=X-YZ:128
  756.  
  757.     SDP parsers should ignore bandwidth fields with  unknown  modifiers.
  758.     Modifiers  should  be alpha-numeric and, although no length limit is
  759.     given, they are recommended to be short.
  760.  
  761. Times, Repeat Times and Time Zones
  762.  
  763. t=<start time>    <stop time>
  764.  
  765. +   ``t'' fields specify the start and stop times for a conference  ses-
  766.     sion.   Multiple  ``t'' fields may be used if a session is active at
  767.     multiple irregularly  spaced  times;  each    additional  ``t''  field
  768.     specifies an additional period of time for which the session will be
  769.     active.  If the session is active at regular times,     an ``r''  field
  770.     (see  below)  should  be  used  in addition to and following a ``t''
  771.     field - in which case the  ``t'' field specifies the start and  stop
  772.     times of the repeat sequence.
  773.  
  774. +   The first and second sub-fields give the start and    stop  times  for
  775.     the conference respectively.  These values are the decimal represen-
  776.     tation of Network Time Protocol (NTP) time values  in  seconds  [1].
  777.     To convert these values to UNIX time, subtract decimal 2208988800.
  778.  
  779. +   If the stop-time is set to zero, then the session  is  not    bounded,
  780.     though it will not become active until after the start-time.  If the
  781.     start-time is also zero, the session is regarded as permanent.
  782.  
  783.  
  784.  
  785.  
  786. Handley/Jacobson                               [Page 14]
  787.  
  788. INTERNET-DRAFT                           21st Nov 1996
  789.  
  790.  
  791.     User interfaces should strongly discourage the creation of unbounded
  792.     and     permanent  sessions  as they give no information about when the
  793.     session is actually going to terminate, and so make scheduling  dif-
  794.     ficult.
  795.  
  796.     The general assumption may be made, when displaying     unbounded  ses-
  797.     sions that have not timed out to the user, that an unbounded session
  798.     will only be active until half an hour from the current time or  the
  799.     session start time, whichever is the later.     If behaviour other than
  800.     this is required, an  end-time  should  be    given  and  modified  as
  801.     appropriate     when  new  information becomes available about when the
  802.     session should really end.
  803.  
  804.     Permanent sessions may be shown to the user as  never  being  active
  805.     unless  there are associated repeat times which state precisely when
  806.     the session will be active.     In general, permanent    sessions  should
  807.     not     be  created for any session expected to have a duration of less
  808.     than 2 months, and should be discouraged for  sessions  expected  to
  809.     have a duration of less than 6 months.
  810.  
  811.  
  812. +   It is prohibited for the start time to be after the stop time.
  813.  
  814. r=<repeat interval> <active duration> <list of offsets from start-time>
  815.  
  816. +    ``r'' fields specify repeat times for a session.  For example, if a
  817.     session is active at 10am on Monday and 11am on Tuesday for one hour
  818.     each week for three months, then the <start time> in the correspond-
  819.     ing ``t'' field would be the NTP representation of 10am on the first
  820.     Monday, the <repeat interval> would be 1 week, the <active duration>
  821.     would  be  1  hour,     and the offsets would be zero and 25 hours. The
  822.     corresponding ``t'' field stop time would be the NTP  representation
  823.     of    the  end  of the last session three months later. By default all
  824.     fields are in seconds, so the ``r'' and ``t'' fields might be:
  825.  
  826.     t=3034423619 3042462419
  827.     r=604800 3600 0 90000
  828.  
  829.      To make announcements more compact, times    may  also  be  given  in
  830.     units  of  days, hours or minutes.    The syntax for these is a number
  831.     immediately followed by a single  case-sensitive  character.   Frac-
  832.     tional  units  are    not  allowed  -     a  smaller  unit should be used
  833.     instead.  The following unit specification characters are allowed:
  834.  
  835.         d - days (86400 seconds)
  836.         h - minutes (3600 seconds)
  837.         m - minutes (60 seconds)
  838.         s - seconds (allowed for completeness but not recommended)
  839.  
  840.  
  841.  
  842. Handley/Jacobson                               [Page 15]
  843.  
  844. INTERNET-DRAFT                           21st Nov 1996
  845.  
  846.  
  847.     Thus, the above announcement could also have been written:
  848.  
  849.     r=1d 1h 0 25h
  850.  
  851.     Monthly and yearly repeats cannot currently     be  directly  specified
  852.     with  a  single SDP repeat time - instead separate "t" fields should
  853.     be used to explicitly list the session times.
  854.  
  855. z=<adjustment time> <offset> <adjustment time> <offset> ....
  856.  
  857. +   Should it be necessary to schedule a repeated session which spans  a
  858.     change  from daylight-saving time to standard time or vice-versa, it
  859.     is necessary to specify offsets from the base repeat times. This  is
  860.     necessary  because    different  time     zones    change time at different
  861.     times of day, different countries change to or from daylight time on
  862.     different dates, and some countries to not have daylight saving time
  863.     at all.
  864.  
  865.     Thus in order to schedule a session that is at the same time  winter
  866.     and     summer,  it must  be possible to specify unambiguously by whose
  867.     time zone a     session  is  scheduled.   To  simplify     this  task  for
  868.     receivers,    we  allow the sender to specify the NTP time that a time
  869.     zone adjustment happens and the offset from the time when  the  ses-
  870.     sion  was  first  scheduled.  The  ``z''  field allows the sender to
  871.     specify a list of these adjustment times and offsets from  the  base
  872.     time.
  873.  
  874.     An example might be:
  875.  
  876.     z=2882844526 -1h 2898848070 0
  877.  
  878.     This specifies that at time 2882844526 the time base  by  which  the
  879.     session's repeat times are calculated is shifted back by 1 hour, and
  880.     that  at  time  2898848070    the  session's    original  time    base  is
  881.     restored.    Adjustments  are  always relative to the specified start
  882.     time - they are not cumulative.
  883.  
  884. +   If a session is likely to last several years, it  is  expected  that
  885.     the     session  announcement will be modified periodically rather than
  886.     transmit several years worth of adjustments in one announcement.
  887.  
  888.  
  889.  
  890. Encryption Keys
  891.  
  892. k=<method>
  893. k=<method>:<encryption key>
  894.  
  895.  
  896.  
  897.  
  898. Handley/Jacobson                               [Page 16]
  899.  
  900. INTERNET-DRAFT                           21st Nov 1996
  901.  
  902.  
  903. +   In countries where encrypted sessions are not prohibited by law, the
  904.     session description protocol may be used to convey encryption keys.
  905.  
  906. +   A key field is permitted before the first media entry (in which case
  907.     it    applies to all media in the session), or for each media entry as
  908.     required.
  909.  
  910. +   The format of keys and their usage is  outside  the     scope    of  this
  911.     document, but see [3].
  912.  
  913.  
  914. +   The method indicates the mechanism to be used to obtain a usable key
  915.     by    external  means,  or from the encoded encryption key given.  The
  916.     following methods are defined:
  917.  
  918.  
  919.     k=clear:<encryption key>
  920.     The encryption key (as described in [3] for  RTP  media     streams
  921.     under  the  AV    profile)  is  included untransformed in this key
  922.     field.
  923.  
  924.     k=base64:<encoded encryption key>
  925.     The encryption key (as described in [3] for  RTP  media     streams
  926.     under the AV profile) is included in this key field but has been
  927.     base64 encoded because it includes characters  that  are  prohi-
  928.     bited in SDP.
  929.  
  930.     k=uri:<URI to obtain key>
  931.     A Universal Resource  Identifier  as  used  by    WWW  clients  is
  932.     included in this key field.  The URI refers to the data contain-
  933.     ing the key, and may require  additional  authentication  before
  934.     the  key  can be returned.  The key should not be obtained until
  935.     the user wishes to join the session to reduce synchronisation of
  936.     requests to the WWW server(s).
  937.  
  938.     k=prompt
  939.     No key is included in this SDP description, but the  session  or
  940.     media  stream  referred     to by this key field is encrypted.  The
  941.     user should be prompted for the key when attempting to join  the
  942.     session,  and this user-supplied key should then used to decrypt
  943.     the media streams.
  944.  
  945.  
  946. Attributes
  947.  
  948. a=<flag>
  949. a=<attribute>:<value>
  950.  
  951.  
  952.  
  953.  
  954. Handley/Jacobson                               [Page 17]
  955.  
  956. INTERNET-DRAFT                           21st Nov 1996
  957.  
  958.  
  959. A media field may also have any     number     of  attributes     (``a''     fields)
  960. which are media specific.  Attribute fields may be of two forms:
  961.  
  962. +   flag  attributes.    A  flag     attribute  is    simply     of   the   form
  963.     ``a=<flag>''.   These are binary attributes, and the presence of the
  964.     attribute conveys that the attribute is ``true''.  An example  might
  965.     be ``a=recvonly''.
  966.  
  967. +   value   attributes.       A   value   attribute   is    of   the    form
  968.     ``a=<attribute>:<value>''.     An  example  might be that a whiteboard
  969.     could have the value attribute ``a=orient:landscape''
  970.  
  971. Attribute interpretation depends on the media tool being invoked.   Thus
  972. receivers  of  session    descriptions  should  be  configurable    in their
  973. interpretation of announcements in general and of attributes in particu-
  974. lar.
  975.  
  976. Attribute fields (``a'' fields) can also be added before the first media
  977. field.     These    attributes  would  convey  additional  information  that
  978. applies to the conference as a whole rather than  to  individual  media.
  979. An example might be the conference's floor control policy.
  980.  
  981. Media Announcements
  982.  
  983. m=<media>  <port>  <transport> <fmt list>
  984.  
  985. A session announcement may contain  a  number  of  media  announcements.
  986. Each media announcement starts with an ``m'' field, and is terminated by
  987. either the next ``m'' field or by the end of the  session  announcement.
  988. A media field also has several sub-fields:
  989.  
  990.  
  991. +   The first sub-field is the media type.  Currently defined media  are
  992.     ``audio'',    ``video'', ``whiteboard'', ``text'' and ``data'', though
  993.     this list may be extended as  new  communication  modalities  emerge
  994.     (e.g., telepresense or conference control).
  995.  
  996.  
  997. +   The second sub-field is the transport port to which the media stream
  998.     will be sent.  The meaning of the transport port depends on the net-
  999.     work being used as specified in the relevant ``c'' field and on  the
  1000.     transport protocol defined in the third sub-field.    Other ports used
  1001.     by the media application (such as the RTCP port, see [2]) should  be
  1002.     derived algorithmically from the base media port.
  1003.  
  1004.     For transports based on UDP, the value should be in the  range  1024
  1005.     to 65535 inclusive.     For RTP compliance it should be an even number.
  1006.     If the port is allocated randomly by the creating application, it is
  1007.  
  1008.  
  1009.  
  1010. Handley/Jacobson                               [Page 18]
  1011.  
  1012. INTERNET-DRAFT                           21st Nov 1996
  1013.  
  1014.  
  1015.     recommended     that  ports  above 5000 are chosen as, on Unix systems,
  1016.     ports below 5000 may be allocated  automatically  by  the  operating
  1017.     system.
  1018.  
  1019.     For applications where hierarchically encoded streams are being sent
  1020.     to    a unicast address, it may be necessary to specify multiple tran-
  1021.     sport ports.  This is done using a similar notation to that used for
  1022.     IP multicast addresses in the ``c'' field:
  1023.  
  1024.         m=<media> <port>/<number of ports> <transport> <fmt list>
  1025.  
  1026.     In such a case, the ports used depend  on  the  transport  protocol.
  1027.     For RTP, only the even ports are used for data and the corresponding
  1028.     one-higher odd port is used for RTCP.  For example:
  1029.  
  1030.         m=video 3456/2 RTP/AVP 31
  1031.  
  1032.     would specify that ports 3456 and 3457 form one  RTP/RTCP  pair  and
  1033.     3458  and  3459 form the second RTP/RTCP pair.  RTP/AVP is the tran-
  1034.     sport protocol and 31 is the format (see below).
  1035.  
  1036.     It is illegal for both multiple addresses to  be  specified     in  the
  1037.     ``c''  field  and  for  multiple  ports to be specified in the ``m''
  1038.     field in the same session announcement.
  1039.  
  1040.  
  1041. +   The third sub-field is the transport protocol.  The transport proto-
  1042.     col     values     are  dependent     on  the address-type field in the ``c''
  1043.     fields. Thus a ``c'' field of IP4 defines that the transport  proto-
  1044.     col     runs  over  IP4.   For      IP4, it is normally expected that most
  1045.     media traffic will be carried as RTP over UDP.  However,  some  com-
  1046.     monly  used     applications  such as vat [5] do not use RTP.    Thus the
  1047.     following  transport protocols are defined:
  1048.  
  1049.  
  1050.     - RTP/AVP  -  the  IETF's  Realtime     Transport  Protocol  using  the
  1051.       Audio/Video profile carried over UDP.
  1052.  
  1053.     - VAT  - LBL's Visual Audio Tool packet format carried over UDP.
  1054.  
  1055.     - UDP  - User Datagram Protocol
  1056.  
  1057.  
  1058.     If an application uses a single combined propriety media format  and
  1059.     transport  protocol     over  UDP, then simply specifying the transport
  1060.     protocol as UDP and using the format field to distinguish  the  com-
  1061.     bined protocol is recommended.  If a transport protocol is used over
  1062.     UDP     to  carry  several  distinct  media  types  that  need     to   be
  1063.  
  1064.  
  1065.  
  1066. Handley/Jacobson                               [Page 19]
  1067.  
  1068. INTERNET-DRAFT                           21st Nov 1996
  1069.  
  1070.  
  1071.     distinguished  by a session directory, then specifying the transport
  1072.     protocol and media format separately is necessary.    VAT and RTP  are
  1073.     examples  of transport protocols that carry multiple payload formats
  1074.     that must be distinguished by the session directory for it    to  know
  1075.     how to start appropriate tools, relays, mixers or recorders.
  1076.  
  1077.     The main reason to specify the transport protocol in addition to the
  1078.     media  format is that the same standard media formats may be carried
  1079.     over different transport protocols even when the network protocol is
  1080.     the     same  -  for example vat PCM audio and RTP PCM audio.    In addi-
  1081.     tion, relays  and  monitoring  tools  that    are  transport    protocol
  1082.     specific but format independent are possible.
  1083.  
  1084.     For RTP media streams operating under the  RTP  Audio/Video     Profile
  1085.     [3],  the  protocol field is ``RTP/AVP''.  Should other RTP profiles
  1086.     be defined in the future, their profiles will be  specified     in  the
  1087.     same way.  For example, the protocol field ``RTP/XYZ'' would specify
  1088.     RTP operating under a profile whose short name is ``XYZ''.
  1089.  
  1090. +   The fourth and subsequent sub-fields are media formats.   For  audio
  1091.     and video, these will normally be a media payload type as defined in
  1092.     the RTP Audio/Video Profile.
  1093.  
  1094.     When a list of payload formats is given, this implies  that     all  of
  1095.     these  formats  may     be  used in the session, but the first of these
  1096.     formats is the default format for the session.
  1097.  
  1098.     For media whose transport protocol is not  RTP  or    UDP  the  format
  1099.     field  is  protocol     specific.  Such formats should be defined in an
  1100.     additional specification document.
  1101.  
  1102.     For media whose transport protocol is RTP, SDP can be used    to  pro-
  1103.     vide  a  dynamic binding of media encoding to RTP payload type.  The
  1104.     payload names in the RTP AV Profile     do  not  specify  unique  audio
  1105.     encodings (in terms of clock rate and number of audio channels), and
  1106.     so they are not used directly in SDP format     fields.   Instead,  the
  1107.     payload  type number should be used to specify the format for static
  1108.     payload types and the payload  type     number     along    with  additional
  1109.     encoding  information  should be used for dynamically allocated pay-
  1110.     load types.
  1111.  
  1112.     An example of a static payload type is u-law PCM coded single  chan-
  1113.     nel     audio    sampled     at 8KHz.  This is completely defined in the RTP
  1114.     Audio/Video profile as payload type 0, so the media field for such a
  1115.     stream sent to UDP port 3456 is:
  1116.  
  1117.         m=video 3456 RTP/AVP 0
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Handley/Jacobson                               [Page 20]
  1123.  
  1124. INTERNET-DRAFT                           21st Nov 1996
  1125.  
  1126.  
  1127.     An example of a dynamic payload type is 16 bit linear encoded stereo
  1128.     audio  sampled  at 16KHz.  If we wish to use dynamic RTP/AVP payload
  1129.     type 98 for such a stream, additional  information    is  required  to
  1130.     decode it:
  1131.  
  1132.         m=video 3456 RTP/AVP 98
  1133.         a=rtpmap:98 L16/16000/2
  1134.  
  1135.     The general form of an rtpmap attribute is:
  1136.  
  1137.         a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]
  1138.  
  1139.     For audio streams, <encoding parameters> optionally specifies number
  1140.     of    audio  channels.   For video streams, no encoding parameters are
  1141.     currently specified.
  1142.  
  1143.     Up to one rtpmap attribute can  be    define    for  each  media  format
  1144.     specified.    Thus we might have:
  1145.  
  1146.         m=audio 12345 RTP/AVP 96 97 98
  1147.         a=rtpmap:96 L8/8000
  1148.         a=rtpmap:97 L16/8000
  1149.         a=rtpmap:98 L16/11025/2
  1150.  
  1151.  
  1152.     Experimental encoding formats can also be  specified  in  this  way.
  1153.     RTP     formats  that    are  not registered with IANA as standard format
  1154.     names must be preceded by ``X-''.  Thus a new experimental redundant
  1155.     audio  stream  called  GSMLPC using dynamic payload type 99 could be
  1156.     specified as:
  1157.  
  1158.         m=video 3456 RTP/AVP 99
  1159.         a=rtpmap:99 X-GSMLPC/8000
  1160.  
  1161.     Such an experimental encoding requires  that  any  site  wishing  to
  1162.     receive  the  media stream has relevant configured state in its ses-
  1163.     sion directory to know which tools are appropriate.
  1164.  
  1165.     Note that RTP audio formats typically  do  not  include  information
  1166.     about  the    number    of  samples  per  packet.   If a non-default (as
  1167.     defined in the RTP Audio/Video Profile) packetisation  is  required,
  1168.     the``ptime'' attribute is used as given below.
  1169.  
  1170.     For more details on RTP audio and video formats, see [3].
  1171.  
  1172. +   Predefined formats for UDP protocol non-RTP media are as below.
  1173.  
  1174.     Whiteboard Formats:
  1175.  
  1176.  
  1177.  
  1178. Handley/Jacobson                               [Page 21]
  1179.  
  1180. INTERNET-DRAFT                           21st Nov 1996
  1181.  
  1182.  
  1183.       WB:   LBL Whiteboard (transport: UDP)
  1184.  
  1185.  
  1186.     Text Formats:
  1187.  
  1188.  
  1189.       NT:   UCL Network Text Editor (transport: UDP)
  1190.  
  1191.  
  1192. Suggested Attributes
  1193.  
  1194. The following attributes are suggested.     Since application  writers  may
  1195. add new attributes as they are required, this list is not exhaustive.
  1196.  
  1197.  
  1198. a=cat:<category>
  1199.     This attribute gives the dot-separated hierarchical category of  the
  1200.     session.   This  is to enable a receiver to filter unwanted sessions
  1201.     by category.  It would probably  have  been     a  compulsory    separate
  1202.     field,  except  for     its  experimental nature at this time.     It is a
  1203.     session attribute.
  1204.  
  1205. a=keywds:<keywords>
  1206.     Like the cat attribute, this is to assist  identifying  wanted  ses-
  1207.     sions at the receiver.  It is a session attribute.
  1208.  
  1209. a=ptime:<packet time>
  1210.     This gives the length of time in  milliseconds  represented     by  the
  1211.     media  in a packet. This is probably only meaningful for audio data.
  1212.     It should not be necessary to know ptime to decode RTP or vat audio,
  1213.     and       it     is    intended       as     a    recommendation   for   the
  1214.     encoding/packetisation of audio.  It is a media attribute.
  1215.  
  1216. a=recvonly
  1217.     This specifies that the tools should be started in receive-only mode
  1218.     where applicable. It can be either a session or media attribute.
  1219.  
  1220. a=sendrecv
  1221.     This specifies that the tools should be started in send and     receive
  1222.     mode.  This is necessary for interactive conferences with tools such
  1223.     as wb which defaults to receive only mode. It can be either     a  ses-
  1224.     sion or media attribute.
  1225.  
  1226. a=sendonly
  1227.     This specifies that the tools should be started in    send-only  mode.
  1228.     Typically  this  may be used where a different unicast address is to
  1229.     be used for a traffic destination than for a traffic source.  It can
  1230.     be    either    a session or media attribute, but would normally only be
  1231.  
  1232.  
  1233.  
  1234. Handley/Jacobson                               [Page 22]
  1235.  
  1236. INTERNET-DRAFT                           21st Nov 1996
  1237.  
  1238.  
  1239.     used as a media attribute.
  1240.  
  1241. a=orient:<whiteboard orientation>
  1242.     Normally this is only used in a whiteboard media  specification.  It
  1243.     specifies  the orientation of a the whiteboard on the screen.  It is
  1244.     a media attribute.    Permitted values are `portrait', `landscape' and
  1245.     `seascape' (upside down landscape).
  1246.  
  1247. a=type:<conference type>
  1248.     This specifies the type of the  conference.      Suggested  values  are
  1249.     `broadcast',  `meeting',  and `moderated'.    `recvonly' should be the
  1250.     default for `type:broadcast' sessions, `type:meeting'  should  imply
  1251.     `sendrecv' and `type:moderated' should imply the use of a floor con-
  1252.     trol tool and that the media tools are started so as to ``mute'' new
  1253.     sites joining the conference.
  1254.  
  1255.     Specifying the attribute type:test is also suggested as a hint that,
  1256.     unless  explicitly    requested  otherwise, receivers can safely avoid
  1257.     displaying this session description to users.
  1258.  
  1259.     type is a session attribute.
  1260.  
  1261.  
  1262. a=charset:<character set>
  1263.     This specifies the character set to be used to display  the     session
  1264.     name  and information data.     By default, an ISO 8859-1 character set
  1265.     is used.  If an ISO 8859-1 character set is not suitable, the use of
  1266.     unicode  (ISO  10646)  [6],[7],  as specified in RFC1641 [8] is sug-
  1267.     gested.  In particular, the UTF-7 (RFC1642)     [9]  encoding    is  sug-
  1268.     gested with the following SDP attribute:
  1269.  
  1270.         a=charset:unicode-1-1-utf-7
  1271.  
  1272.     This is a session attribute; if this attribute is present,    it  must
  1273.     be before the first media field.
  1274.  
  1275.  
  1276. a=framerate:<frame rate>
  1277.     This gives the maximum  video  frame  rate    in  frames/sec.      It  is
  1278.     intended  as  a  recommendation  for  the  encoding     of  video data.
  1279.     Decimal representations of    fractional  values  using  the    notation
  1280.     "<integer>.<fraction>" are allowed.     It is a media attribute, and is
  1281.     only defined for video media.
  1282.  
  1283.  
  1284. a=quality:<quality>
  1285.     This gives a suggestion for     the  quality  of  the    encoding  as  an
  1286.     integer value.
  1287.  
  1288.  
  1289.  
  1290. Handley/Jacobson                               [Page 23]
  1291.  
  1292. INTERNET-DRAFT                           21st Nov 1996
  1293.  
  1294.  
  1295.     The intention of the quality attribute for video  is  to  specify  a
  1296.     non-default     trade-off  between  frame-rate and still-image quality.
  1297.     For video, the value in the range 0 to 10, with the     following  sug-
  1298.     gested meaning:
  1299.  
  1300. 10    - the best still-image quality the compression scheme can give.
  1301.  
  1302. 5    - the default behaviour given no quality suggestion.
  1303.  
  1304. 0    - the worst still-image quality the  codec  designer  thinks  is
  1305.     still usable.
  1306.  
  1307.  
  1308. 6.1.  Communicating Conference Control Policy
  1309.  
  1310. There is some debate over the way conference control  policy  should  be
  1311. communicated.  In general, the authors believe that an implicit declara-
  1312. tive style of specifying conference control is desirable where possible.
  1313.  
  1314. A simple declarative style uses     a  single  conference    attribute  field
  1315. before    the  first  media  field, possibly supplemented by flags such as
  1316. `recvonly' for some of the media tools.     This conference attribute  con-
  1317. veys the conference control policy.  An example might be:
  1318.  
  1319.         a=type:moderated
  1320.  
  1321. In some cases, however, it is possible that this may be insufficient  to
  1322. communicate  the  details  of  an unusual conference control policy.  If
  1323. this is the case, then a conference attribute specifying  external  con-
  1324. trol  might  be set, and then one or more ``media'' fields might be used
  1325. to specify the conference control tools and configuration data for those
  1326. tools.    A fictional example might be:
  1327.  
  1328.         ...
  1329.         a=type:external-control
  1330.         m=audio 12345 RTP/AVP 0
  1331.         m=video 12347 RTP/AVP 31
  1332.         m=whiteboard 12349 UDP WB
  1333.         m=control 12341 UDP SCCP
  1334.         a=mode:chaired
  1335.         a=chair:128.16.64.2
  1336.         a=video:follows-audio
  1337.         a=audio:on-demand
  1338.         a=audio:chair-mutes-mike
  1339.         a=whiteboard:chaired
  1340.  
  1341. In this fictional example (i.e., this is not  implemented  anywhere),  a
  1342. general     conference  attribute    is  specified  stating    that  conference
  1343.  
  1344.  
  1345.  
  1346. Handley/Jacobson                               [Page 24]
  1347.  
  1348. INTERNET-DRAFT                           21st Nov 1996
  1349.  
  1350.  
  1351. control will be provided by an external tool,  and  specific  attributes
  1352. are given to specify the control policy that tool should use.
  1353.  
  1354. In this document, only the former style of conference  control    declara-
  1355. tion  is  specified, though we recognise that some variant on the latter
  1356. may also be used eventually.
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Handley/Jacobson                               [Page 25]
  1403.  
  1404. INTERNET-DRAFT                           21st Nov 1996
  1405.  
  1406.  
  1407. Appendix A: SDP Grammar
  1408.  
  1409. announcement ::=    proto-version
  1410.             origin-field
  1411.             session-name-field
  1412.             information-field
  1413.             uri-field
  1414.             email-fields
  1415.             phone-fields
  1416.             connection-field
  1417.             bandwidth-fields
  1418.             time-fields
  1419.             key-field
  1420.             attribute-fields
  1421.             media-descriptions
  1422.  
  1423. proto-version ::=    "v=" (DIGIT)+
  1424.             ;this draft describes version 0
  1425.  
  1426. origin-field ::=    "o=" username space
  1427.             sess-id space sess-version space
  1428.             nettype space addrtype space
  1429.             addr newline
  1430.  
  1431. session-name-field ::=    "s=" text
  1432.  
  1433. information-field ::=    ["i=" text newline]
  1434.  
  1435. uri-field ::=        ["u=" uri newline]
  1436.  
  1437. email-fields ::=    ("e=" email-address newline)*
  1438.  
  1439. phone-fields ::=    ("p=" phone-number newline)*
  1440.  
  1441.  
  1442. connection-field ::=    ["c=" nettype space addrtype space
  1443.             connection-address newline]
  1444.             ;a connection field must be present
  1445.             ;in every media description or at the
  1446.             ;session-level
  1447.  
  1448.  
  1449. bandwidth-fields ::=    ("b=" bwtype ":" bandwidth newline)*
  1450.  
  1451.  
  1452. time-fields ::=        ( "t=" start-time space stop-time
  1453.               (newline repeat-fields)* newline)+
  1454.             [zone-adjustments newline]
  1455.  
  1456.  
  1457.  
  1458. Handley/Jacobson                               [Page 26]
  1459.  
  1460. INTERNET-DRAFT                           21st Nov 1996
  1461.  
  1462.  
  1463.  
  1464. repeat-fields ::=    "r=" repeat-interval space typed-time
  1465.             (space typed-time)+
  1466.  
  1467.  
  1468. zone-adjustments ::=    time space [``-''] typed-time
  1469.             (space time space [``-''] typed-time)*
  1470.  
  1471.  
  1472. key-field ::=        ["k=" key-type newline]
  1473.  
  1474.  
  1475. key-type ::=        "prompt" |
  1476.             "clear:" key-data |
  1477.             "base64:" key-data |
  1478.             "uri:" uri
  1479.  
  1480.  
  1481. key-data ::=        printable-ascii
  1482.  
  1483.  
  1484. attribute-fields ::=    ("a=" attribute newline)*
  1485.  
  1486.  
  1487. media-descriptions ::=    ( media-field
  1488.               information-field
  1489.               connection-field
  1490.               bandwidth-fields
  1491.               key-field
  1492.               attribute-fields )*
  1493.  
  1494.  
  1495. media-field ::=        "m=" media space port ["/" integer]
  1496.              space proto (space fmt)+ newline
  1497.  
  1498.  
  1499. media ::=        (alpha-numeric)+
  1500.             ;typically "audio", "video", "whiteboard"
  1501.             ;or "text"
  1502.  
  1503.  
  1504. fmt ::=            (alpha-numeric)+
  1505.             ;typically an RTP payload type for audio
  1506.             ;and video media
  1507.  
  1508.  
  1509. proto ::=        (alpha-numeric)+
  1510.             ;typically "RTP/AVP", "VAT", or "UDP" for IP4
  1511.  
  1512.  
  1513.  
  1514. Handley/Jacobson                               [Page 27]
  1515.  
  1516. INTERNET-DRAFT                           21st Nov 1996
  1517.  
  1518.  
  1519.  
  1520. port ::=        (DIGIT)+
  1521.             ;should in the range "1024" to "65535" inclusive
  1522.             ;for UDP based media ;random allocation should
  1523.             ;only assign above UDP port "5000".
  1524.  
  1525.  
  1526. attribute ::=        att-field ":" att-value | att-field
  1527.  
  1528.  
  1529. att-field ::=        (ALPHA)+
  1530.  
  1531.  
  1532. att-value ::=        (att-char)+
  1533.  
  1534.  
  1535. att-char ::=        alpha-numeric | "-"
  1536.             ;is this too tight a restriction
  1537.  
  1538.  
  1539. sess-id ::=        (DIGIT)+
  1540.             ;should be unique for this originating username/host
  1541.  
  1542.  
  1543. sess-version ::=    (DIGIT)+
  1544.             ;0 is a new session
  1545.  
  1546.  
  1547. connection-address ::=    multicast-conf-address | multicast-scoped-address
  1548.             | unicast-address
  1549.  
  1550.  
  1551. multicast-conf-address ::=
  1552.             "224.2." decimal_uchar "." decimal_uchar "/" ttl
  1553.             [ "/" integer ]
  1554.             ;multicast addresses may be in a larger range
  1555.             ;but only these should be assigned by an sdp tool
  1556.  
  1557.  
  1558. multicast-scoped-address ::=
  1559.             "239."    decimal_uchar "." decimal_uchar "."
  1560.             decimal_uchar "/" ttl [ "/" integer ]
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Handley/Jacobson                               [Page 28]
  1571.  
  1572. INTERNET-DRAFT                           21st Nov 1996
  1573.  
  1574.  
  1575.  
  1576. ttl ::=            decimal_uchar
  1577.  
  1578. start-time ::=        time | "0"
  1579.  
  1580. stop-time ::=        time | "0"
  1581.  
  1582. time ::=        POS-DIGIT 9*DIGIT
  1583.             ;sufficient for 2 more centuries
  1584.  
  1585.  
  1586. repeat-interval ::=    typed-time | interval-time
  1587.  
  1588.  
  1589. typed-time ::=        (DIGIT)+ [fixed-len-time-unit]
  1590.  
  1591.  
  1592. interval-time ::=    (DIGIT)+ variable-len-time-unit
  1593.  
  1594.  
  1595. fixed-len-time-unit ::= ``d'' | ``h'' | ``m'' | ``s''
  1596.  
  1597.  
  1598. variable-len-time-unit ::= ``Y'' | ``M''
  1599.  
  1600.  
  1601. bwtype ::=        (alpha-numeric)+
  1602.  
  1603. bandwidth ::=        (DIGIT)+
  1604.  
  1605.  
  1606. username ::=        alpha-numeric
  1607.             ;perhaps this is too restrictive...
  1608.  
  1609.  
  1610. email-address ::=    email | email "(" text ")" | text "<" email ">"
  1611.  
  1612.  
  1613. email ::=        ;defined in RFC822
  1614.  
  1615.  
  1616. uri::=            ;defined in RFC1630
  1617.  
  1618.  
  1619. phone-number ::=    phone | phone "(" text ")" |
  1620.             text "<" phone ">"
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Handley/Jacobson                               [Page 29]
  1627.  
  1628. INTERNET-DRAFT                           21st Nov 1996
  1629.  
  1630.  
  1631.  
  1632. phone ::=        "+" POS-DIGIT (space | "-" | DIGIT)+
  1633.             ;there must be a space or hyphen between the
  1634.             ;international code and the rest of the number.
  1635.  
  1636.  
  1637. nettype ::=        "IN"
  1638.             ;list to be extended
  1639.  
  1640.  
  1641. addrtype ::=        "IP4" | "IP6"
  1642.             ;list to be extended
  1643.  
  1644.  
  1645. addr ::=        unicast-address
  1646.  
  1647.  
  1648. unicast-address ::=    IP4-address | IP6-address
  1649.  
  1650.  
  1651. IP4-address ::=        b1 "." decimal_uchar "." decimal_uchar "." b4
  1652. b1 ::=            decimal_uchar
  1653.             ;less than "224"; not "0" or "127"
  1654. b4 ::=            decimal_uchar
  1655.             ;not "0"
  1656.  
  1657. IP6-address ::=        ;to be defined
  1658.  
  1659.  
  1660. text ::=        (printable-iso8859-1)+ | (unicode-1-1-utf-7)+
  1661.             ;unicode requires a "a=charset:unicode-1-1-utf-7"
  1662.             ;attribute to be used
  1663.  
  1664.  
  1665. printable-iso8859-1 ::= ;8 bit ascii character
  1666.             ;decimal 9 (TAB), 32-126 and 161-255
  1667.  
  1668.  
  1669. unicode-1-1-utf-7 ::=    unicode-safe
  1670.             ;defined in RFC 1642
  1671.  
  1672.  
  1673. decimal_uchar ::=    DIGIT
  1674.             | POS-DIGIT DIGIT
  1675.             | (1 2*DIGIT)
  1676.             | (2 (0|1|2|3|4) DIGIT)
  1677.             | (2 5 (0|1|2|3|4|5))
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Handley/Jacobson                               [Page 30]
  1683.  
  1684. INTERNET-DRAFT                           21st Nov 1996
  1685.  
  1686.  
  1687.  
  1688. integer ::= POS-DIGIT (DIGIT)*
  1689.  
  1690.  
  1691. alpha-numeric ::=    ALPHA | DIGIT
  1692.  
  1693.  
  1694. printable-ascii ::=    unicode-safe | "~" | "
  1695.  
  1696.  
  1697. DIGIT ::=        0 | POS-DIGIT
  1698.  
  1699.  
  1700. POS-DIGIT ::=        1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
  1701.  
  1702.  
  1703. ALPHA ::=        a | b | c | d | e | f | g | h | i | j | k |
  1704.             l | m | n | o  | p | q | r | s | t | u | v |
  1705.             w | x | y | z | A | B | C  | D | E | F | G |
  1706.             H | I | J | K | L | M | N | O | P |  Q | R |
  1707.             S | T | U | V | W | X | Y | Z
  1708.  
  1709.  
  1710. unicode-safe ::=    alpha-numeric |
  1711.             "'" | "(" | ")" | "'" | "-" | "." | "/" | ":" |
  1712.             "?" | """ | "#" | "$" | "&" | "*" | ";" | "<" |
  1713.             "=" | ">" | "@" | "[" | "]" | "^" | "_" | "`" |
  1714.             "{" | "|" | "}" | "+" | space | tab
  1715.             ;although unicode allows newline and carriage
  1716.             ;return, we don't here.
  1717.  
  1718.  
  1719. space ::=        ;ascii code 32
  1720. tab ::=            ;ascii code 9
  1721. newline ::=        ;ascii code 10
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Handley/Jacobson                               [Page 31]
  1739.  
  1740. INTERNET-DRAFT                           21st Nov 1996
  1741.  
  1742.  
  1743. Appendix C: Authors' Addresses
  1744.  
  1745. Mark Handley
  1746. Information Sciences Institute
  1747. c/o MIT Laboratory for Computer Science
  1748. 545 Technology Square
  1749. Cambridge, MA 02139
  1750. United States
  1751. electronic mail: mjh@isi.edu
  1752.  
  1753. Van Jacobson
  1754. MS 46a-1121
  1755. Lawrence Berkeley Laboratory
  1756. Berkeley, CA 94720
  1757. United States
  1758. electronic mail: van@ee.lbl.gov
  1759.  
  1760.  
  1761. Acknowledgments
  1762.  
  1763. Many people in the IETF MMUSIC working    group  have  made  comments  and
  1764. suggestions contributing to this document.  In particular, we would like
  1765. to thank Eve Schooler, Steve Casner, Bill  Fenner,  Allison  Mankin  and
  1766. Ross Finlayson.
  1767.  
  1768. References
  1769.  
  1770. [1] D. Mills, ``Network Time Protocol version 2 specification and imple-
  1771. mentation", RFC1119, 1st Sept 1989.
  1772.  
  1773. [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A Tran-
  1774. sport Protocol for Real-Time Applications'', RFC 1889
  1775.  
  1776. [3] H. Schulzrinne, ``RTP Profile for Audio and Video  Conferences  with
  1777. Minimal Control'', RFC 1890
  1778.  
  1779. [4] M. Handley, ``SAP - Session Announcement Protocol'', INTERNET-DRAFT,
  1780. November 25th 1996.
  1781.  
  1782. [5] V. Jacobson, S. McCanne, ``vat -  X11-based     audio    teleconferencing
  1783. tool'' vat manual page, Lawrence Berkeley Laboratory, 1994.
  1784.  
  1785. [6] ``The Unicode Standard, Version 1.1'': Version 1.0, Volume    1  (ISBN
  1786. 0-201-56788-1), Version 1.0, Volume 2 (ISBN 0-201-60845-6), and "Unicode
  1787. Technical Report #4, The Unicode Standard, Version 1.1" (available  from
  1788. The Unicode Consortium, and soon to be published by Addison- Wesley).
  1789.  
  1790. [7] ISO/IEC 10646-1:1993(E) Information Technology--Universal  Multiple-
  1791.  
  1792.  
  1793.  
  1794. Handley/Jacobson                               [Page 32]
  1795.  
  1796. INTERNET-DRAFT                           21st Nov 1996
  1797.  
  1798.  
  1799. octet Coded Character Set (UCS).
  1800.  
  1801. [8] D. Goldsmith, M. Davis, ``Using Unicode with MIME'',  RFC1641,  July
  1802. 1994
  1803.  
  1804. [9] D. Goldsmith, M. Davis, ``UTF-7 - A Mail-Safe Transformation  Format
  1805. of Unicode'', RFC1642, July 1994
  1806.  
  1807.  
  1808.  
  1809.  
  1810.  
  1811.  
  1812.  
  1813.  
  1814.  
  1815.  
  1816.  
  1817.  
  1818.  
  1819.  
  1820.  
  1821.  
  1822.  
  1823.  
  1824.  
  1825.  
  1826.  
  1827.  
  1828.  
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Handley/Jacobson                               [Page 33]
  1851.  
  1852.