Internet Engineering Task Force MMUSIC WG Internet Draft Schulzrinne ietf-mmusic-scip-00.txt GMD February 22, 1996 Expires: 8/1/96 Simple Conference Invitation Protocol STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. ABSTRACT The conference invitation protocol (SCIP) is an application-level protocol for inviting users to multimedia conferences. Network users are identified by their universal communication identifier, usually their electronic mail address. SCIP offers personal mobility by supporting forwarding and redirection. It can reuse the general email infrastructure, including DNS MX records, mailing lists and aliases. The protocol combines aspects of HTTP and SMTP and can re-use their security mechanism. The protocol is extensible in methods and parameters and is designed to allow interoperation with ITU-T T.124 (Generic Conference Control). Extension to VCR-control are possible as well. The protocol supports both loose and tight conference styles. Schulzrinne [Page 1] Internet Draft SCIP February 22, 1996 1 Introduction 1.1 Purpose The conference invitation protocol allows users to invite other users as well as automatic applications to point-to-point or multicast conferences. It provides extensions 1.2 Requirements This document uses the same words as RFC 1123 for defining the significance of each particular requirement. These words are: must: This word or the adjective "required" means that the item is an absolute requirement of the specification. should: This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. may: This word or the adjective "optional" means that this item is truly optional. One implementation may choose to include the item because a particular application requires it or because it enhances the product, for example, another implementation may omit the same item. An implementation is not compliant if it fails to satisfy one or more of the must requirements for the protocols it implements. An implementation that satisfies all the must and all the should requirements is said to be "unconditionally compliant"; one that satisfies all the must requirements but not all the should requirements for its protocols is said to be "conditionally compliant". 1.3 Terminology This specification uses a number of terms to refer to the roles played by participants in SCIP communications. The definitions of client, server and proxy are similar to those used by HTTP. Calling party: The party initiating a conference invitation. Note that the calling party does not have to be the same as the one creating a conference. Called party: The person or service that the calling party is trying to invite to a conference. Schulzrinne [Page 2] Internet Draft SCIP February 22, 1996 Conference: A logical grouping of several sessions. A conference is identified by a globally unique conference identifier. Conference member: The union of all session members. Client: An application program that establishes connections for the purpose of sending requests. Clients may or may not interact directly with a human user. Session member: A member of a session, either an application used by a human or a support tool of some kind (e.g., a video recorder). Server: An application program that accepts connections in order to service requests by sending back responses. A server interacts with the called user agent to determine whether to accept a call. Session: A single media, identified by a common media identifier. In a multicast setting, each session has a single multicast address. Proxy: An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them, with possible translation, on to other servers. A proxy must interpret, and, if necessary, rewrite a request message before forwarding it. [calling] user agent: The client application which initiates a request. Any given program may be capable of acting both as a client and a server. A typical multimedia conference controller would act as a client to initiate calls or invite others to conferences and as a server to accept invitations. However, since a server should be reachable even if the conference controller is not running, server and conference controller may well be separate. The protocol between server and conference controller is a local matter, but SCIP itself may be used for implementation efficiency. In that case, the conference controller may well initiate a connection to the server after being started by the server. The issues are somewhat similar to the separation of MUA and MTA on a local host, with the added difficulty that synchronous communication is needed. (TBD: move this section?) 1.4 Overall Operation The protocol can be used to either initiate a two-party multimedia Schulzrinne [Page 3] Internet Draft SCIP February 22, 1996 call, similar to a phone call, to an invidual or to invite an individual to a multicast conference. Except for using unicast or multicast network addresses in the media description, there is no difference in protocol operation or end system behavior. Conferences may take place immediately or in the future. The protocol can convey information about conferences that repeat a determinate or indeterminate number of times. The protocol can also "invite" a recorder to a conference and thus serve as a control mechanism for accessing media-on-demand services. The SCIP protocol is based on HTTP and employs many of its concepts, data types, and protocol operations. The protocol is designed so that it could share a single server with HTTP, although that is usually not desirable. The called party is identified by its electronic mail (RFC 822) address. It is also possible that the UCI differs from the (primary) electronic mail address, but this is not recommended. The domain named in the UCI should also accepts SMTP connections, but may simply forward them to a regular electronic mail exchange. The caller contacts the server, located according to Section 1.4.1, with a call request. The request contains information about the originator, subject and urgency of the call and, typically for conferences, the anticipated duration. For conferences, out-of-band contact information such as email addresses, phone numbers or URIs may also be offered. The call request indicates the desired media, together with their encoding and network parameters such as the unicast or multicast address, protocol type and port number. The callee may either accept the call, forward the call or reject the call. When accepting a call, the called party returns a subset of the media listed in the Accept field of the request, namely those media it is prepared to receive. The called party must not generate any media types not listed in the Accept field. If several parties are being invited in parallel, a second round of negotiation may be needed. For large-scale conferences, a separate, multicast-based negotiation protocol may be preferable, but has not been specified. When rejecting a call, the server may offer a reason or a time to call back at (using the Retry-After field). If the called server runs on a mail exchange host, the called user will likely not be reachable on that host. Rather, that server will use a local mechanism to locate the user within the local environment. This local mechanism is beyond the scope of this specification; examples include multicast queries, user registration services or use of active badges. The server may also map a user name to a temporary IP address to address the common situation of users Schulzrinne [Page 4] Internet Draft SCIP February 22, 1996 connected to the Internet by a modem. A server can operate in redirect or proxy mode. In redirect mode, the server returns a status code and header fields indicating a possible current location of the called party. In proxy mode, the server maintains the incoming SCIP connection while it establishes new client SCIP connection to the intended called party. It then simply forwards the response of the called to the caller. A caller should cache the current location of the called party so that it can short-circuit the lookup process for future calls. There is no indication of lifetime (say, via an Expires header), since user behavior is unpredictable. As in HTTP, the called server closes the connection. There is a keep-alive mechanism that allows the client to request that the server maintain the connection. This can be used for tight conference control and T.120 interoperation. However, it is also possible to request conference parameter changes even when the initial connection was torn down after call acceptance by establishing a new connection. A forwarding or name resolution may yield more than one name, for example, when expanding a mailbox using SMTP EXPN. The user agent should offer a choice of "reach first" or "reach all". In the "reach first" case, the caller tries each UCI in turn, only the first one accepts the call. In the "reach all" case, the client tries to invite as many as possible. It may do this either in parallel or sequentially. (It may be useful to describe UCIs, similar to the HTTP/1.1 URI field, for example, to indicate, for example, several departments within an organization or the language-abilities of different possible parties.) Note that while a response may indicate several UCIs, a single SCIP request can only act on a single UCI. In a multiprocess operating system, a single server per host will typically be running continuously as a priviledged process. For incoming calls, the server can either determine the call disposition automatically, based on some user-specified rules, or signal to the user an incoming call, e.g. through an acoustic signal or a pop-up window. If the called party accepts the call, the server then starts the necessary conferencing applications and passes the parameters conveyed by the call request to them. 1.4.1 Resolving Addresses A client implementing the SCIP protocol should follow the following steps in locating a server belonging to the callee address. For brevity, the action "check if valid server" implies attempting to connect to the address at the service TCP port. If the connection attempt succeeds, the sequence is aborted. o Strip the domain part from the addr-spec. Schulzrinne [Page 5] Internet Draft SCIP February 22, 1996 o If a location has been cached for this UCI, check if called party is present there. o If the domain has a DNS A record, check if valid server. o If the domain has a DNS SRV resource record [1], check if valid server. o If the domain has a DNS MX record, check (in order of MX preference) if one of the records points to a valid server. Note that this procedure makes it possible to have a SCIP-only server (i.e., one not acting as an MTA) by simply adding it as an MX record, usually with lower priority than a true MTA. Mail delivery will simply skip the SCIP-only server, just as SCIP will skip any non-SCIP mail exchange hosts. If the procedure above does not yield a SCIP server or if the user name is not recognized by a SCIP server, a client should attempt to contact the mail transfer agent for the same domain using SMTP and expand the name using the SMTP EXPN and VRFY commands. If EXPN yields more than one name, the client should treat this as a group call and contact all list members in the manner described above. The client should contact list members in parallel. A client may limit the number of parallel connection attempts; a user agent acting a client may request confirmation if the number of addresses exceeds a given threshold. SMTP expansion can be used to offer the service of life- long UCIs, without actually handling calls. If all attempts to contact a SCIP server fail, a user agent may attempt to send a MIME message to the address, with content type message/cip 2 Notational Conventions and Generic Grammar 2.1 Augmented BNF See RFC HTTP 1.1, Section 2.1. 2.2 Basic Rules See RFC HTTP 1.1, Section 2.2. The attribute-value bag is not used. phone-number = E123 / phrase "<" E123 ">" / E123 comment E123 = "+" country-code (SPACE / "-") 1*(DIGIT / "A" / "B" / "C" / "D" / "#" / "*" / "." / "-") Schulzrinne [Page 6] Internet Draft SCIP February 22, 1996 country-code = 1*3 DIGIT time = rfc1123-date / hex-time hex-time = *HEX ; time in seconds since 1 Jan 1900 3 Protocol Parameters 3.1 Product Tokens See HTTP/1.1, Section 3.8. 3.2 Universal Communication Identifiers SCIP defines universal communication identifiers (UCIs) as a generalization of mailboxes according to RFC 822. UCIs can be used for electronic mail or interactive communications. UCIs have the format of RFC 822 addr-specs, possibly with some extensions. TBD: Possibly affix port number (with :port) to allow user-space implementations and sharing of HTTP servers? A special form of UCI is an E.164 international telephone number, written as a numeric string preceded by a plus-sign, followed by the country code. A phone number may contain the digits 0 through 9, the letters A through D, the star (ASCII 0x2A) and the pound sign (ASCII 0x23). A E.164 UCI may employ the ASCII period "." (ASCII 0x2E) or dash "-" (ASCII 0x2D) for grouping. These are ignored when processing. An application may either directly dial this telephone number through a local computer-telephony interface, establish a phone-call through a locally-configured LAN-telephony gateway or offer the user the number for manual dialing through an appropriate interface. It is the responsibility of the computer-telephony interface or gateway to translate the number to a number that is valid at the origination point of the telephone call, e.g., by removing the country code and prefixing the remainder with any long- distance access code, or dialing the appropriate international access code. (Note: Implementation of the full AT modem dial commands such as pauses or choosing between tone and pulse dialing is not useful, since dialing conventions will differ from location to location.) E.140 telephone numbers can be easily distinguished from mailboxes by the presence of the leading plus sign and the absence of the at-sign. (TBD: Can a mailbox start with a +?) 3.3 UCIs as Uniform Resource Identifiers Since UCIs are meant as universal identifiers for both synchronous and asynchronous communications, SCIP reuses the mailto URI scheme (see Section XX, RFC 1738). It is suggested that the mailto URI be Schulzrinne [Page 7] Internet Draft SCIP February 22, 1996 extended to encompass telephone numbers as well. The user interface of browsers implementing SCIP should offer the user the choice of either sending electronic mail or trying to establish real-time communication. Since the number of parameters and the total length of a typical conference description is large, it is recommended to use a http or ftp or similar scheme to retrieve an object of type message/scip, defined in Appendix A. It is also possible to use the "data" URI scheme [2] to convey information of type message/cip 4 SCIP Message SCIP headers may be folded as described in RFC 822. 5 Request A request from a client to a server includes, within the first line of that message, the method to be applied to the UCI, the identifier of the called party, and the protocol version in use. (Note: there is no need for a HTTP/0.9 backward compatible request.) Request-Line = method SP UCI SP "SCIP/1.0" CRLF 5.1 Method 6 Response A server returns a response message to a request. Response = Status-Line *(General Header / Response header) CRLF Status-Line = SCIP-Version SP Status-code SP Reason-phrase CRLF An example: SCIP/1.0 302 Moved Temporarily Location: secretary@westwing.whitehouse.gov Location: security@eastwing.whitehouse.gov Schulzrinne [Page 8] Internet Draft SCIP February 22, 1996 7 Method Definitions For T.124 compatibility, additional methods will be defined in the future. 7.1 CALL Call the user identified by the called-UCI. 7.2 CHANGE Change parameters of the conference. 7.3 CLOSE Close the conference. 8 Status Code Definitions 8.1 Informational (1xx) Currently, no 1xx type status codes are defined for SCIP. The HTTP codes 100 (Continue) and 101 (Switching Protocols) are not applicable. Progress indication such as "ringing" may be useful. 8.2 Successful (2xx) The HTTP status codes 201 (Created), 202 (Accepted), 203 (Non- Authoritative Information), 204 (No Content), 205 (Reset Content), 206 (Partial Content) are not applicable and must not be sent in response to a SCIP method. 8.2.1 200 OK The request has succeeded. The information returned with the response depends on the method used in the request: CALL The call has been accepted by the called party. 8.3 Redirection 3xx 8.3.1 301 Moved Permanently The user identfied by the UCI has moved permanently and any future calls should be to the new UCI returned in the Location field. If a user may be at several locations, several Location fields may be returned, with the client then trying to contact the new locations in turn or in parallel. (HTTP only allows one Location field.) Schulzrinne [Page 9] Internet Draft SCIP February 22, 1996 8.3.2 302 Moved Temporarily The user identified by the UCI has moved 8.4 Caller Error 4xx The 4xx class of status codes is intended for cases in which the client (caller) seems to have erred. Status codes 400 (Bad Request), 401 (Unauthorized), 402 (Payment Required), 403 (Forbidden), 404 (Not Found), 405 (Method Not Allowed), 406 (None Acceptable), 408 (Request Timeout), 410 (Gone) have the same interpretation as for HTTP, with URI replaced by UCI. 8.5 Callee Error 5xx The 5xx class of status codes indicates that the server is incapable of completing the request. The codes 500 (Internal Server Error), 501 (Not Implemented), 502 (Bad Gateway), 503 (Service Unavailable), 504 (Gateway timeout) are to be interpreted in the same way as in HTTP 1.1, except that URI is to be replaced by UCI. Busy conditions, i.e., where the called party indicates she does not wish to receive calls, or a busy signal from a telephony gateway, are indicated by status code 503. If known, a Retry-After field can give an indication when a new call may succeed. 9 Header Field Definitions 9.1 Accept Accept = "Accept" ":" #( media-range [";" "ttl" "=" ttl-value] [";" "addr" "=" net-address] [";" "cbw" "=" bandwidth] [";" "bw" "=" bandwidth] [";" "key" "=" encryption-key] [";" "id" "=" media-id] [";" "i" "=" information] [";" "tp" "=" ("rtp" / other-transport-protocol)] [";" "pt" "=" payload-type] [";" "dir" "=" "sendonly" / "recvonly" / "hduplex" / "fduplex"] ) media-range = type "/" (subtype / "*") type = ("audio" / "video" / "application") subtype = (audio-enc ["." sr "." ch]) / video-enc / application) net-address = [(host / multicast-address)] [":" port] Schulzrinne [Page 10] Internet Draft SCIP February 22, 1996 sr =