home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mmusic / mmusic-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  5KB  |  141 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Mark Handley/University College London
  5.  
  6. Minutes of the Multiparty Multimedia Session Control Working Group
  7. (MMUSIC)
  8.  
  9. An on-line copy of the minutes and the accompanying PostScript slides
  10. are available from ftp://ftp.isi.edu/confctrl/minutes in the files
  11. ietf.7.95 and slides.7.95.tar.
  12.  
  13. The Multiparty Multimedia Session Control Working Group (MMUSIC) met for
  14. two sessions on July 17 and 18 at the 33rd IETF.
  15.  
  16.  
  17.  
  18. Interworking With The ITU
  19.  
  20. Carsten Bormann gave a presentation (slides.7.95.a) of the possibilities
  21. for interworking between the ITU T.120 family for multimedia
  22. conferencing and Internet-based approaches to conferencing.  The ITU
  23. appears to be moving towards using RTP or an RTP-like protocol for media
  24. data streams, but it is unclear how the conference control functionality
  25. encompassed in the T.120 suite would be achieved over the wide area
  26. Internet.  Initially the ITU seems to be interested only in LAN
  27. interoperability.
  28.  
  29. Three interoperability scenarios were presented, and the implications
  30. examined:
  31.  
  32.  
  33.   1. T.120 terminal phones in to ``classical'' IETF multicast session
  34.   2. Internet protocols only used locally behind a gateway
  35.   3. Tight interworking with the illusion of homogeneity
  36.  
  37.  
  38. The issues where there are potential incompatibilities include:
  39.  
  40.  
  41.    o Resource control
  42.    o Addressing:  use of multicast
  43.    o Session setup:  prescriptive session description vs.  negotiated
  44.    o Security:  cryptography vs.  link setup authentication
  45.  
  46.  
  47. The details of these interoperability scenarios are discussed in more
  48. detail in draft-bormann-mmusic-itu-interop-00.txt.
  49.  
  50. This presentation was followed by a discussion of how the MMUSIC Working
  51. Group should relate to the T.120 work.  The rough consensus was that the
  52. group should pay attention to the ITU work, and not needlessly replicate
  53. T.120's conference control functionality in an incompatible way.
  54. However, the opinion was expressed that the group's current emphasis on
  55. wide area scalable multicast-based conferencing was desirable, and that
  56. we shouldn't sacrifice the benefits of multicast based sessions to
  57. conform to the ITU tightly coupled model.  No real conclusion was
  58. reached, except that a building-blocks approach was advocated.
  59.  
  60.  
  61.  
  62. Vertical Control Protocols
  63.  
  64. Joerg Ott gave a presentation (slides.7.95.b) of two vertical control
  65. protocols (control protocols between local applications and controllers)
  66. developed at TU Berlin:  The LASSO Dictionary and the Conference
  67. Information and Request Protocol (CIRP). Unlike CCCP and the control
  68. architecture described by Henning Schulzrinne (see minutes.4.95), these
  69. consist of a central (for each participant) information store, and an
  70. access protocol to this data store.  The dictionaries object store is an
  71. acyclic directed graph, which is sufficient to reflect T.120 conference
  72. data, as well as more loosely couple conferences.  CIRP complements the
  73. dictionary and allows a more flexible asynchronous event triggered
  74. interaction style, but still requires a single conference controller per
  75. user.  Work is currently in progress to unify the dictionary and CIRP.
  76.  
  77.  
  78.  
  79. Changes Made To The Session Description Protocol
  80.  
  81. Mark Handley presented the changes that have been made to the Session
  82. Description Protocol since the Danvers IETF (slides.7.95.c).  The
  83. current version of the draft is available from
  84. http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps.
  85.  
  86. The main changes are:
  87.  
  88.  
  89.    o SDP is no longer a superset of the sd protocol.
  90.  
  91.    o The ``c'' fields have been split into channel and time fields.
  92.  
  93.    o Repeat time fields have been completely re-worked.
  94.  
  95.    o Origin fields have been completely re-worked, and now uniquely
  96.      identify a session announcement.
  97.  
  98.    o Bandwidth fields have been reworked somewhat.
  99.  
  100.    o Media fields have been reworked somewhat.
  101.  
  102.    o The Session Description Protocol has been separated into a separate
  103.      draft from the announcement protocol that carries it.
  104.  
  105.  
  106. In general, the changes attempt to make the protocol more generic and
  107. more widely applicable.
  108.  
  109. A number of minor problems with the protocol or the description in the
  110. current draft were noted.  All these changes are fairly minor, but the
  111. most significant are:
  112.  
  113.  
  114.    o The ``o'' field allows spaces in the address.  The ``c'' field does
  115.      not.  The incompatibility should be resolved.
  116.  
  117.    o For unicast, the existing ``c'' field may not be sufficient to
  118.      identify whether the address is to send to or receive from or some
  119.      other semantics.  This should be investigated further.
  120.  
  121.    o <address type> in ``o'' and ``c'' fields should probably be two
  122.      fields:  <network type> and <address type>.
  123.  
  124.    o For unicast, hierarchical encodings need to be able to use multiple
  125.      ports (for multicast they use multiple multicast addresses).  The
  126.      notation <base address>/<number of addresses> should be extended
  127.      to ports in the media field.
  128.  
  129.  
  130. A new draft will be released shortly addressing these issues.  Assuming
  131. this does not raise new objections, the consensus of the group was that
  132. we should submit SDP for consideration as a Proposed Standard around the
  133. time of the Dallas IETF.
  134.  
  135.  
  136. Other Business
  137.  
  138. It was flagged that the Agreement Protocol is now available as an
  139. Internet-Draft:  draft-ietf-mmusic-agree.txt,ps
  140.  
  141.