NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 18-Mar-98
Chair(s):
Ruth Lang <rlang@sri.com>
Eve Schooler <schooler@cs.caltech.edu>
Mark Handley <mjh@isi.edu>
Joerg Ott <jo@cs.tu-berlin.de>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Transport Area Advisor:
Allyn Romanow <allyn@mci.net>
Mailing Lists:
General Discussion:confctrl@isi.edu
To Subscribe: confctrl-request@isi.edu
Archive: ftp://ftp.isi.edu/confctrl/confctrl.mail
Description of Working Group:
The Multiparty Multimedia session Control (MMUSIC) Working Group (WG) is chartered to develop Internet standards track protocols to support Internet teleconferencing sessions. MMUSIC's focus is on supporting the loosely-controlled conferences that are pervasive on the MBone today. However, the WG also will ensure that its protocols are general enough to be used in managing tightly-controlled sessions.
To date, MMUSIC has drafted protocols for:
- distributing session descriptions -- Session Description Protocol (SDP) and Session Announcement Protocol (SAP),
- providing security for session announcements -- SAP Security,
- controlling on-demand delivery of real-time data -- Real-Time Stream Protocol (RTSP),
- initiating sessions and inviting users -- Session Initiation Protocol (SIP), and
- managing tightly-controlled sessions -- Simple Conference Control Protocol (SCCP).
In addition, the WG has drafted two informational documents: the first describes the architectural framework for MMUSIC, and the second describes interoperability scenarios for ITU- and Internet-based teleconferencing systems.
The WG's protocols reflect coordination with other IETF efforts related to multimedia conferencing (e.g., AVT, RSVP). In addition, the WG will collaborate with liaisons to ITU standards bodies and industry consortiums as appropriate to ensure interoperable standards (e.g., SIP/SAP/SDP with ITU H.323 and H.332).
The WG has defined two sets of goals -- immediate goals to be accomplished over the next several months, and longer-term goals which will be reviewed and possibly revised after the immediate goals are met. The immediate goals include bringing several protocols to Proposed Standard (SDP, RTSP), or Experimental RFC status (SAP), and to produce Informational RFCs for the informational drafts listed above. The longer-term goals are to bring the remaining protocols to Proposed Standard status (SIP, SAP Security, SAP), to investigate the requirements for a next-generation session description protocol, and to continue the development of SCCP.
Goals and Milestones:
Jul 97 |
|
Conduct WG Last Call for SAP Internet-Draft |
Jul 97 |
|
Submit a revised Internet Multimedia Conferencing Architecture I-D. |
Jul 97 |
|
Submit SDP to the IESG for consideration as a Proposed Standard. |
Jul 97 |
|
Submit a revised SIP I-D. |
Aug 97 |
|
Submit a revised ITU Interoperability Scenarios I-D. |
Aug 97 |
|
Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol. |
Oct 97 |
|
Conduct WG Last Call for RTSP Internet-Draft. |
Oct 97 |
|
Submit Internet-Draft on Internet Multimedia Conferencing Architecture. |
Nov 97 |
|
Submit RTSP to IESG for consideration as a Proposed Standard. |
Nov 97 |
|
Submit ITU Interoperability Scenarios Internet-Draft to IESG for consideration as an Informational RFC. |
Jan 98 |
|
Conduct WG Last Call for SIP Internet-Draft. |
Feb 98 |
|
Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard. |
Apr 98 |
|
Conduct WG Last Call for SAP Security Internet-Draft. |
Apr 98 |
|
Conduct second WG Last Call for SAP. |
May 98 |
|
Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard. |
May 98 |
|
Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· SDP: Session Description Protocol
· Real Time Streaming Protocol (RTSP)
· SIP: Session Initiation Protocol
· SAP Security Using Public Key Algorithms
· SIP URL Scheme
· The Internet Multimedia Conferencing Architecture
· SIP Call Control Services
· SIP Security Using Public Key Algorithms
No Request For Comments
Minutes of the Multiparty Multimedia Session Control (mmusic) Working Group
Co-Chairs:
Mark Handley, mjh@isi.edu
Ruth Lang, rlang@sri.com
Joerg Ott, jo@tzi.org
Eve Schooler, schooler@cs.caltech.edu
The Multiparty Multimedia Session Control Working Group (MMUSIC) met for one session on March 31st at the 41st IETF. These notes, prepared by Eve Schooler, summarize the presentations given and recount issues raised and their resolution, if any, during these presentations. An on-line copy of these minutes and the accompanying slides are available from the MMUSIC archive area ftp://ftp.isi.edu/confctrl/minutes in the files ietf.3.98 and slides.3.98.{tar, tar.Z}. Individual slide presentations can be obtained from the directory slides.3.98.
I. SIP
Mark Handley of USC/Information Sciences Institute gave a detailed overview of SIP status. See the accompanying slides sip.{ps,ppt}. In particular, he focused on an improved SIP security architecture and presented the outstanding issues that remain before SIP is to be advanced to Proposed Standard. As discussed at the DC IETF, the call-control functionality has been split from the base spec and was discussed later in the meeting.
Issues raised:
· With end-to-end encryption, if you encrypt you may not get the same routing as when you do not encrypt. In addition, a Response-Key header is needed for bootstrapping.
· We expect the Response-Key namespace to be an IANA registered space and to extend the HTTP authentication space.
· Note that the fields that may change go above the Authorization header.
· One recommendation was that the PGP encryption scheme should be brought in line with IPSEC, both internally and externally.
· If Hide is used, how can you determine Max-Fanout? Although encrypted after Via, we can still count the number. Questions also arose about exact semantics, i.e., could there be breadth and depth aspects to it? Note that this cannot be controlled when multicast is used.
· - For multicast requests, parameters need to be specified for the SRM-like back-off behavior of respondents. There was some concern that multicast might be a source of security problems, in that a forged source address might redirect ACK response traffic to another address. To limit the impact of such a scenario, only consider multicast with local scope for the base specification.
· Several proposals were made regarding how to handle the receipt of multiple 2xx responses. Accept (ACK) the first one that comes back, but any others should lead to responses with more information (e.g., the call was refused someone else picked up at the same time), which can be processed more effectively by a smart user agent. Does this conflict with the call control proposal for a 3-way merge? In either case, we need to clarify that these scenarios are different. Another opinion was that because this is an example of ill-defined temporal behavior, all the SIP spec should say is that at least one callee should get connected. Yet, another opinion expressed was that SIP should forbid that 1 INVITE leads to more than 1 callee. In any event, it was suggested that the default behavior be flexible enough to support more complicated call control should it be necessary later on.
· When asked if we should constrain the time when the inviter begins receiving voice, the consensus was that the callee should be allowed to start sending either when a Status message is sent by the caller or when an ACK is received from the caller.
· Proxies probably should be allowed to encrypt a request, but we do not want to encourage or set precedent that proxies mess with random fields.
· Interface addresses vs FQDNs in Via? Recommend FQDNs in Via, but allow interface addresses because there are boxes out there that do not have FQDNs.
Once the SIP I-D freezes, an interoperability testing session is needed for SIP implementations.
II. SIP Call Control
Jonathan Lennox of Columbia University presented the latest call-control I-D on behalf of Henning Schulzrinne and Jonathan Rosenberg. See the accompanying slides sip-cc.ps. Much heated discussion ensued. Overall it was felt that the I-D introduced complex enough behavior, with functionality as yet untried, that (1) considerably more detail was needed in the I-D and (2) implementation experience was strongly requested.
The issues raised:
· Extensions to the Location header:
- Regarding "features=permanent", who decides what's permanent vs temporary?
- The client doing the registration? What's the semantic difference and impact (e.g., on caching) of the two? Further details are needed.
· Call-Dispostion:
- Further clarification was requested of how Queued is supposed to cause a client to behave. One comment was that the do-not-respond option would seem to change the mandatory behavior of SIP. In fact some felt that SIP was not necessarily the right protocol to perform this role (which begins to resemble instant messages a la the NOTIFY method discussed in the PIPR BOF). What happens when two or more of these features happen at once?
· New headers Also, Replaces and Requested-by:
- How does authentication work with these headers?
- Why not use BYE in a call transfer?
- Table 1 and 2 need to clarify Location usage as R or r or both.
- Precise error messages for each scenario are still a big issue to be resolved.
In terms of feature redundancy, what is the difference between an INVITE with an Also and Replaces (to myself), and a BYE with an Also of someone else? Although the former (INVITE with Replaces of self) is rather awkward, it is legal to do a blind transfer with this mechanism. However, we need to be careful (e.g., with PBX's) that there remains a single user in conference (imagine robot-to-robot 3rd party transfers).
· Semantics:
- (To, From, Call-Id) uniquely identifies a transaction and "leg" of a call. But, some felt that this scheme overloaded the endpoint names.
In addition, there was general discussion about the distinction between various identifiers: the user, session, and call ids. In particular, the question was asked, what's the difference between a session and a call? Does a call refer to a single "leg" or INVITE, whereas session is the overall "object" among all users; or alternatively, is the call meant to cover the overall conference? In any event, clarification is needed.
· Open Issues:
Asked how a third-party requester should be informed of the progress and result of a request, people felt none of the proposed solutions were ideal (STATUS request, application/sip payload, 1xx responses). It was reiterated that more precise error message handling may help here.
· Examples:
A more palatable example other than telemarketing was requested :-) In discussing the issue of transitioning from a mesh to an MCU, one issue raised was if there is a method of notification of all parties on the calls for meshes.
III. SAP Security
Ian Brown from University College London reported that SAP security is nearly complete. The only major change since the last IETF meeting was making PGP support a MUST and S/MIME support a SHOULD. The draft currently references the old PGP standard (RFC 1991), which mandates RSA and IDEA support, both of which are encumbered algorithms. The solution is to use the new version of PGP, which will be slotted in as soon as possible; it mandates Cast, Triple-DES and Diffie-Hellman, all of which are considered unencumbered. The UCL implementation is almost done and eventually will support the latest version of PGP.
IV. Status of WG Documents
· SAP - Basically SAP is ready to become an Experimental Standard. Although it has clear long-term scaling issues, it is probably appropriate for the next 1 to 2 years. Within a couple month timeframe, the base spec will be merged with the SAP security spec.
· SDP - After resolving outstanding namespace issues between SDP, RTP, and MIME, SDP has been published as RFC 2327 and has advanced to Proposed Standard status. There is some interest in drafting a recommendation on SDP format parameters.
· RTSP - After being stalled on SDP-related issues, RTSP has been published as RFC 2326 and has been advanced to Proposed Standard status.
· SIP - The I-D is on the brink of being re-issued, and should advance to Propose Standard within 2-3 months.
· SAP security - Will be rolled into the SAP base spec.
· SIP security - The current SIP I-D now encompasses this work.
· SIP call-control - Still a fairly controversial topic. The natural home for this work was SIPTEL, but now that SIPTEL has become IPTEL, call control is no longer in the charter. For now, the work will carry on in the MMUSIC working group, but we will collect feedback on a long term home for it.
· Conference Architecture - This I-D is more or less done. We simply need to make sure that it is an accurate representation of what really exists now - as it was originally drafted a couple years ago.
· ITU Interoperability - A moving target! This draft has expired. If rewritten, should it aim to describe what goes in a gateway between MMUSIC and ITU protocols (H.323 and H.245)? The major concern is that we should not get into this business. One suggestion is to re-activate the I-D in IPTEL, if and when several gateway implementations have emerged. One Transport AD advised that such a document was not necessarily needed at this point. However, others thought an I-D that served to compare and contrast MMUSIC and ITU approaches might be useful.
· SCCP - The simple conference control protocol continues evolution as it undergoes implementation. We hope to re-issue the I-D before next IETF.
· The Agreement Protocol - An early I-D in the WG, which has since expired. It is closer in spirit to SCCP, in that it supports general mechanisms for closer coordination sessions with varying policies. There are no current plans to resurrect it, but there is sporadic interest in continuing the work. One related suggestion was to extend SDP to carry more complicated policy information.
· Conference or Coordination Bus - The idea that there exists a local coordination protocol among components on a single host (e.g., among media agents such as audio and video and shared workspaces, which might be used to implement voice-to-follow-video operation, or floor control, etc.). Is this a protocol the working group should take on?