home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mmusic / mmusic-minutes-97apr.txt < prev    next >
Encoding:
Text File  |  1997-05-29  |  8.1 KB  |  158 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4.  
  5.       Multiparty Multimedia Session Control (MMUSIC) Working Group
  6.                     Minutes from the 38th IETF
  7.                       Memphis, Tennessee
  8.                              April 8-9, 1997                         
  9.  
  10.                 Chairs
  11.  
  12.         Mark Handley, mjh@isi.edu
  13.          Ruth Lang, rlang@sri.com
  14.         Eve Schooler, schooler@cs.caltech.edu
  15.  
  16. The Multiparty Multimedia Session Control Working Group (MMUSIC) met
  17. for two sessions on April 8th and 9th at the 38th IETF.  These notes,
  18. prepared by Ruth Lang, summarize the presentations given and recount
  19. issues raised and their resolution, if any, during these
  20. presentations.  An on-line copy of the minutes and the accompanying
  21. The minutes and slides are available from the MMUSIC archive area
  22. ftp://ftp.isi.edu/confctrl/minutes in the files ietf.4.97 and
  23. slides.4.97.(tar, tar.Z}.  Individual slide presentations can be 
  24. obtained from the directory slides.4.97.
  25.  
  26. Mark Handley reiterated the WG Last Call placed for the Session
  27. Description Protocol (SDP) and offered his time in sidebar meetings to
  28. discuss any open issues.  See the slides sdp.ps.
  29.  
  30. Rob Lanphier and Anup Rao discussed the current status and open issues
  31. of the Real Time Streaming Protocol (RTSP). They reviewed changes made
  32. since our last meeting in December including the merger of the
  33. original RTSP (Lanphier/Rao) and RTSP' (Schulzrinne), the maintenance
  34. of the HTTP orientation of RTSP', and the simplification of the
  35. protocol's state machine.  See the slides rtsp.ps.
  36.  
  37. The results of open issue discussions were as follows:
  38.      
  39.    - Use of two HTTP mechanisms (cookies for managing core RTSP server
  40.      state and PEP, an option negotiation method as a replacement for
  41.      the current "Require" field) were discussed.  The former was
  42.      discouraged as it provided too broad of a solution (i.e.,
  43.      overkill) for the RTSP server.  For the latter, the issue of PEP
  44.      maturity with respect to the timeframe for forwarding RTSP to
  45.      Proposed Draft was questioned.  Further deliberation on the this
  46.      topic will occur on the mailing list in light of gaining a better
  47.      knowledge of PEP.
  48.  
  49.    - A speed field whose application would imply fluctuating bandwidth
  50.      usage during a session was encouraged as long as appropriate
  51.      warnings about its potential misuse were included.
  52.  
  53.    - The use of absolute URIs (cf relative URIs) in the Request-URI
  54.      message to reference content was strongly encouraged.
  55.      
  56.    - Further discussion will occur on the mailing list regarding the
  57.      control of multiple streams. It was encouraged, however, that a
  58.      single stream transmitted to n destinations be broken up into n
  59.      separate sessions.
  60.  
  61.    - Sending data to a destination that is not the control source was
  62.      oked for client-defined multicast address oked given inclusion of
  63.      appropriate cautionary statement, and was discouraged (for now)
  64.      for client-defined unicast address.
  65.  
  66. A more detailed account of these issues may be found at
  67. http://www.real.com/prognet/rt/memphis.html.
  68.  
  69. Mark Handley presented the Session Announcement Protocol open issues
  70. including:
  71.  
  72.    - use of a UUID vs IPv4 address for message id + source addr (the
  73.      latter is currently specified).  The recent availability of an
  74.      I-D describing UUIDs will seed well-thought discussion on this
  75.      topic on the mailing list.
  76.  
  77.    - expansion of the current set of payload type fields. Although
  78.      this adds flexibility (i.e., being able to convey other than SDP
  79.      payloads), in practice it does not permit the presumption that
  80.      the multicast address allocation scheme implemented by sdr --
  81.      currently, the most widely-used tool for advertising MBone-based
  82.      sessions -- is being used.  The more general issue of separating
  83.      and documenting this address allocation mechanism arose.
  84.      Although this work is needed, the downside of addressing it in
  85.      the context of the current SAP is that redesign of the current
  86.      mechanism and SAP protocol would be required, thus slowing-down
  87.      progress of an already widely-used protocol to Experimental
  88.      Standard status.
  89.  
  90.    - elimination of key identifiers for encryption as they serve as
  91.      hints to the bad guys.  This move was supported by the group.
  92.  
  93. Mark also presented a proposal to the group to progress the current
  94. SAP, with its security issues intact, to be an Experimental Standard.
  95. With the movement of the SAP Security I-D to Proposed Standard, SAP or
  96. a revision thereof would also then be forwarded to Proposed Standard.
  97. This was met with agreement with the exception of a plea for
  98. documentation of the current address allocation mechanism.  Mark
  99. encouraged that this be brought to the attention of the Transport
  100. Services Area Directors.  See the slides sap.ps.
  101.  
  102. Colin Perkins presented an overview of and open issues for the I-D
  103. "Specification of Security in SAP Using Public Key Algorithms" aka
  104. "SAP Security."  See the accompanying slides sap_security.ps.
  105. SAP itself provides authentication hooks; this
  106. document attempts to define mechanisms that can be put on those hooks.
  107. Open issues included whether the key id field in the SAP header was
  108. required: it was felt that this could move into a specific
  109. authentication block as both PGP and PKCS#7 have key id fields.
  110. Discussion of the need to define a standard privacy header, and
  111. whether the simple public key format defined in the document
  112. (simplified form of PKCS#7) or full PKCS#7 (or both) should be used
  113. was deferred to discussion on the mailing list.
  114.  
  115. Joerg Ott presented "Panel-style Conferencing with H.323 based on
  116. H.332" which described the use of H.332 for loosely coupled
  117. conferences -- a protocol that can be used to create
  118. IETF/MBone-interoperable sessions.  Use of SDP, SAP, and RTP are keys
  119. to this interoperability.  Open issues presented included: SDP/SAP
  120. does not permit dynamic changes to conference parameters as H.332
  121. does, the potential for "floor request" implosions (a Join request on
  122. the H.332 side which would allow the participant to generate content),
  123. and the integration of data protocols -- T.120 style vs SRM style
  124. application protocols -- different applications and application
  125. protocol styles.  Joerg will circulate the H.332 specification to the
  126. mailing list to encourage further discussion.  See the slides
  127. h332over.{ppt, ps}.
  128.  
  129. Mark Handley presented the changes and open issues related to the
  130. Session Invitation Protocol (SIP).  Changes included: "capabilities"
  131. method was changed to "options" to align with RTSP, sequence numbers
  132. were removed from the "path" field, and the "path" field was changed
  133. to "via" to align with RTSP and HTTP (but the semantics are different
  134. so this change is questionable).  Mark noted that the invitation of an
  135. RTSP server into a conference needs explanation in the document. Time
  136. was spent discussing the relationship between SIP and H.323 sessions.
  137. Advantages of SIP were pointed out and discussions about H.323's
  138. shortcomings ensued.  The general notion of SIP providing a more
  139. lightweight mechanism and a different model were what justified its
  140. independent existence but further study and discussion on this is
  141. needed.  It was proposed by Mark that further implementation
  142. experience be gained to aid the "shakedown" process of this proposal
  143. (e.g., continued inclusion or exclusion of some HTTP headers which
  144. have added complexity to the protocol).  See the slides sip.ps.
  145.  
  146. Joerg Ott presented some early results from a MERCI project on the
  147. "Development of a Gateway for SIP/SCCP and H.323 Interaction."  Use of
  148. SIP alone created a set-up mismatch which necessitated some string
  149. pulling by the project team and creation of a situation where the
  150. H.323 conference could be assumed established while the SIP-based side
  151. was not yet established.  Introduction of SCCP to establish a
  152. "control" conference aided this transition and created a workable
  153. model.  Mark Handley questioned what changes to SIP would make this
  154. call model more compatible?  Discussion will occur on the mailing list
  155. on this.  See the slides merci-gw.{ppt, ps}.
  156.  
  157.  
  158.