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