Internet Engineering Task Force SIP WG Internet Draft J.Rosenberg,H.Schulzrinne
draft-ietf-sip-guidelines-00.txtdraft-ietf-sip-guidelines-01.txt dynamicsoft,Columbia U. July 12,November 24, 2000 Expires: January,May, 2001 Guidelines for Authors of SIP Extensions STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. 1 Introduction The Session Initiation Protocol (SIP)  is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. SIP can be extended in numerous ways. New methods, headers andheaders, body types and parameters for existing headers can be defined. This flexibility also means that caution should be exercised when defining extensions, in order to ensure interoperability. In order to facilitate interoperability, this document serves as a set of guidelines for authors of SIP extensions. It points out issues to consider when deciding whether a SIP extension is the right answer for a specific problem. It then points out issues which extensions should deal with from within thetheir specification. Finally, it discusses common interactions with existing SIP features which often cause difficulties in extensions. 2 Should I define a SIP Extension? The first question to be addressed when defining a SIP extension is: is a SIP extension the best solution to my problem? SIP has been proposed as a solution for numerous problems, including mobility, configuration and management, QoS control, call control, caller preferences, device control, third party call control, and MPLS path setup, to name a few. Clearly, not every problem can be solved by a SIP extension. More importantly, some problems that could be solved by a SIP extension, probably shouldn't. To assist engineers in determining whether a SIP extension is an appropriate solution to their problem, we present two broad criteria. First, the problem should fit into the general purvey of SIPs solution space. Secondly, the solution must conform to the general SIP architectural model. While the first criteria might seem obvious, we have observed that numerous extensions to SIP have been proposed because some function is needed in a device which also speaks SIP. The argument is generally given that "I'd rather implement one protocol than many". As an example, user agents, like all other IP hosts, need some way to obtain their IP address. This is generally done through DHCP . SIPs multicast registration mechanisms might supply an alternate way to obtain an IP address. This would eliminate the need for DHCP in clients. However, we do not believe such extensions are appropriate. We believe that protocols should be defined to provide specific, narrow functions, rather than being defined based on all communications requirements between a pair of devices. The latter approach to protocol design yields modular protocols with broad application. It also facilitates extensibility and growth; single protocols can be removed and changed without affecting the entire system. We observe that this approach to protocol engineering mirrors object oriented software engineering. Our second criteria, that the extension must conform to the general SIP architectural model, ensures that the protocol remains manageable and broadly applicable. 2.1 SIP's Solution Space In order to evaluate the first criteria, it is necessary to define exactly what SIPs solution space is, and what it is not. SIP is a protocol for initiating, modifying, and terminating interactive sessions. This process involves the discovery of ausers, (or more generally, entities that can be communicated with)with, including services, such as voicemail or translation devices) wherever they may be located, so that a description of the session can be delivered to the user. It is assumed that these users or communications entities are mobile, and their point of attachment to the network changes over time. The primary purpose of SIP is a rendezvous function, to allow a request initiator to deliver a message to a recipient wherever they be. Such rendezvous is needed to establish a session, but can be used for other purposes,purposes related to communications, such as querying for capabilities or delivery of an instant message. SIP itself is independent of the session, and the session description is delivered as an opaque body.Much of SIP focuses on this discovery and rendezvous component. Its ability to fork, its registration capabilities, and its routing capabilities are all present for the singular purpose of finding the calleddesired user wherever they may be. As such, features and capabilities such as personal mobility, automatic call distribution, and follow-me are well within the SIP solution space. Session initiation also depends on the ability of the called party to have enough information about the session itself in order to make a decision on whether to join or not. That information includes data about the caller, the purpose for the invitation, and parameters of the session itself. For this reason, SIP includes this kind of information. Part of the process of session initiation is the communication of progress and the final results of establishment of the session. SIP provides this information as well. ThereSIP itself is independent of the session, and the session description is delivered as an opaque body within SIP messages. Keeping SIP independent of the sessions it initiates and terminates is fundamental. As such, there are many functions that SIP explicitly does not provide. It is not a session management protocol or a conference control protocol. The particulars of the communications within the session are outside of SIP. This includes features such as media transport, voting and polling, virtual microphone passing, chairman election, floor control, and feedback on session quality. SIP is not a resource reservation protocol for sessions. This is fundamentally because (1) SIP is independent of the underlying session it establishes, and (2) the path of SIP messages is completely independent from the path that packets for a session may take. The path independence refers to paths within a providers network, and the set of providers itself. For example, it is perfectly reasonable for a SIP message to traverse a completely different set of autonomous systems than the audio in a session SIP establishes. SIP is not a transfer protocol. It is not meant to send large amounts of data unrelated to SIPs operation. It is not meant as a replacement for HTTP. This is for numerous reasons, one of which is that SIP's recommended mode of operation is over UDP. Sending large messages over SIP can lead to fragmentation at the IP layer and thus poor performance in even mildly lossy networks. This is not to say that carrying payloads in SIP messages is never a good thing; in many cases, the data is very much related to SIPs operation. However, SIP is not meant to carry large amounts of data unrelated to SIPs general function. The only exception to this rule is REGISTER, which is, in many ways, its own protocol within SIP. REGISTER is ideally suited for configuration and exchange of application layer data between a user agent and its proxy. This may entail exchange of modest amounts of data. Because of the infrequency of such exchanges and their limitation in extent (i.e., usually not multi-hop), it is appropriate to transfer larger amounts of content in REGISTER. In such cases, TCP is preferred. SIP is not meant to be a general RPC mechanism. None of its user discovery and registration capabilities are needed for RPC, neither are most of its proxy functions. As it is not an ideal transfer protocol, it is not good at carrying serialized objects of any large size. SIP is not meant to be used as a strict PSTN signaling replacement. It is not a superset of ISUP. While it can support gatewaying of PSTN signaling, and can provide many features present in the PSTN, the mere existence of a feature or capability in the PSTN is not a justification for its inclusion in SIP. Extensions needed to support telephony must meet the other criteria described here. SIP is a poor control protocol. It is not meant to be used for one entity to tell another to pick up or answer a phone, send audio using a particular codec, or change a configuration parameter. Control protocols have different trust relationships than is assumed in SIP, and are more centralized in architecture than SIP, which is a very distributed protocol. There are many network layer services needed to make SIP function. These include quality of service, mobility, and security, among others. Rather than building these capabilities into SIP itself, they should be developed outside of SIP, and then used by it. Specifically, any protocol mechanisms that are needed by SIP, but are also needed by many other application layer protocols, should not be addressed within SIP. 2.2 SIP Architectural Model We describe here some of the primary architectual assumptions which underly SIP. Extensions which violate these assumptions should be examined more carefully to determine their appropriateness for SIP. Session independence: SIP is independent of the session it establishes. This includes the type of session, be it audio, video, game, chat session, or virtual reality. SIP operation should never be dependent on some characteristic of the session. SIP is not specific to VoIP only. Any extensions to SIP MUSTmust consider the application of SIP to a variety of different session types. SIP and Session Path Independence: We have already touched on this once, but it is worth noting again. The set of routers and/or networks and/or autonomous systems traversed by SIP messages and the packets in the session are unrelated. They may be the same in some cases, but it is fundamental to SIPs architecture that they need not be the same. Extensions which only work under some assumption of overlap are not generally applicable to SIPs operation and should be scrutinized carefully. Multi-provider and Multi-hop: SIP assumes that its messages will traverse the Internet. That is, SIP works through multiple networks administered by different providers. It is also assumed that SIP messages traverse many hops (where each hop is a proxy). Extensions which only work in single hop or single provider networks may not be appropriate for SIP. Transactional: SIP is a request/response protocol, possibly enhanced with intermediate responses. Many of the rules of operation in SIP are based on general processing of requests and responses. This includes the reliability mechanisms, routing mechanisms, and state maintenance rules. Extensions which add new messages that are not within the request-response model will likely break many aspects of SIP. Proxies can ignore bodies: In order for proxies to scale well, they must be able to operate with minimal message processing. SIP has been engineered so that proxies can always ignore bodies. Extensions which require proxies to examine bodies in order to work will likely lead to serious scaling problems. Proxies don't need to understand the method: Processing of requests in proxies does not depend on the method, except for the well known methods INVITE, ACK, and CANCEL. This allows for extensibility. Extensions that define new methods which must be understood by proxies are NOT RECOMMENDED.not recommended. INVITE messages carry full state: An initial INVITE message for a session is nearly identical (the exception is the tag) to a re-INVITE message to modify some characteristic of the session. This is strongly coupled to the idempotency of SIP requests, but is a different characteristic. Extensions which modify INVITE processing such that data spanning multiple INVITEs must be collected in order to perform some feature, are frowned upon. Generality over efficiency: Wherever possible, SIP has favored general purpose components rather than narrow ones. If some capability is added to support one service, but a slightly broader capability can support a larger variety of services (at the cost of complexity or message sizes), the broader capability is generally preferred. 3 IssuesThe Request URI is the primary key for routing: Forwarding logic at SIP servers depends primarily on the request URI. It is fundamental to be Addressed Given an extension has metthe litmus tests inoperation of SIP that the previous section, there are several issuesrequest URI indicate a resource that, under normal operations, resolves to the desired recipient. Extensions that all extension should take into consideration. 3.1 Backwards Compatibility Oneuse other components of the most important issues to consider is whetherSIP message as the new extension is backwards compatible with baseline SIP. This isprimary routing key, or modify the semantics of the request URI, are frowned upon. Proxies can operate statelessly: SIP allows for great flexibility in the design of proxies. They can operate in fast, stateless modes, or they can maintain complete call and session state, providing advanced services. SIP extensions should insure that such a range of servers can always be built. Therefore, extensions which operate only with stateful proxies, for example, are discouraged. Heterogeneity is the norm: SIP supports hetereogeneous devices. It has built in mechanisms for determining the set of overlapping protocol functionalities. Extensions which only function if all devices support the extension are strongly discouraged. 3 Issues to be Addressed Given an extension has met the litmus tests in the previous section, there are several issues that all extension should take into consideration. 3.1 Backwards Compatibility One of the most important issues to consider is whether the new extension is backwards compatible with baseline SIP. This is tightly coupled with how the Require, Proxy-Require, and Supported  headers are used. If an extension consists of new headers inserted by a user agent in a request with an existing method, and the request cannot be processed reasonably by a proxy and/or user agent without understanding the headers, the extension MUSTmust mandate the usage of the Require and/or Proxy-Require headers in the request. These extensions are not backwards compatible with SIP. The result of mandating usage of these headers means that requests cannot be serviced unless the entities being communicated with also understand the extension. If some entity does not understand the extension, the request will be rejected. The UAC can then handle this in one of two ways. In the first, the request simply fails, and the service cannot be provided. This is basically an interoperability failure. In the second case, the UAC retries the request without the extension. This will preserve interoperability, at the cost of a "dual stack" implementation in a UAC (processing rules for operation with and without the extension). As the number of extensions increases,sczzincreases, this leads to an exponential explosion in the sets of processing rules a UAC may need to implement. The result is excessive complexity. Because of the possibility of interoperability and complexity problems that result from the usage of Require and Proxy-Require, we believe the following guidelines are appropriate: o The usage of these headers in requests for basic SIP services (in particular, session initiation and termination) is NOT RECOMMENDED.strongly discouraged. The less frequently a particular extension is needed in a request, the more reasonable it is to use these headers. o The Proxy-Require header SHOULDshould be avoided at all costs. The failure likelihood in an individual proxy stays constant, but the path failure grows exponentially with the number of hops. On the other hand, the Require header only mandates that a single entity, the UAS, support the extension. Usage of Proxy-Require is thus considered exponentially worse than usage of the Require header. Extensions which define new methods do not need to use the Require header. SIP defines mechanisms which allow a UAC to know whether a new method is understood by a UAS. This includes both the OPTIONS request, and the 405 (Method Not Allowed) response with the Allow header. It is fundamental to SIP that proxies do not need to understand the semantics of a new method in order to process it. If an extension defines a new method which must be understood by proxies in order to be processed, a Proxy-Require header is needed. As discussed above, these kinds of extensions are frowned upon. In order to achieve backwards compatibility for extensions that define new methods, the Allow header is used. There are two types of new methods - those that are used for established sessions (initiated by INVITE, for example), and those that are sent as the initial request to a UA. Since INVITE and its response both SHOULDshould contain an Allow header, a UA can readily determine whether the new method can be supported within the call. For example, if a new method for a mid-call feature, such as hold, were to be defined, the hold button on the UI could be "greyed out" once the call is established, if the new method were not listed in the Allow header. Another type of extension are those which require a proxy to insert headers into a request as it traverses the network, or for the UAS to insert headers into a response. Some extensions can simply insert these headers. IfFor some extensions, if the UAC or UAS does not understand them,these headers, the message can still be processed correctly. These extensions are completely backwards compatible. Most other extensions of this type require that the server only insert the header if it is sure the client understands it. In this case, these extensions will need to make use of the Supported request header mechanism. This mechanism allows a server to determine if the client can understand some extension applied to the response. If an extension is suchextension, so that it requires a servercan apply the extension to insert information into a response which must be understood in order forthe response to be correctly processed, that extension SHOULD make use of. By their nature, these extensions may not always be able to be applied to every response. If an extension requires a proxy to insert a header into a request, and this header needs to be understood by both UAC and UAS to be executed correctly, a combination of the Require and the Supported mechanism will need to be used. The proxy can insert a Require header into the request, given the Supported header is present. An example of such an extension is the SIP Session Timer . Yet another type of extension are thoseis that which definedefines new body types to be carried in SIP messages. If the body type isAccording to the SIP specification, bodies must be conveyedunderstood in order to process a request without usage of MIME multipart ,request. As such, the compatibilityinteroperability issues mirror those ofare similar to new methods. Usage of Accept in INVITE and INVITE responses is is RECOMMENDEDHowever, a new header, Content-Disposition, has been defined that allows a client or server to determine ifindicate that the message body typeis understood for subsequent requests. If a body typeoptional . Usage of optional bodies is to be conveyed inrecommended wherever possible. When a response, that type MUST only be sent if support for it was indicated in an Accept header in the request. If thebody type is tomust be conveyed inunderstood to properly process a request with multipart, that body can either be mandatoryor optional. Mandatory impliesresponse, it is preferred that the request cannot be processed unlesssending entity know ahead of time whether the new body is understood. Optional impliesunderstood by the recipient. For requests that are the request can be processed iffirst in a sequence of exchanges between user agents (such as INVITE), inclusion of Accept in the body is understood. It is RECOMMENDED that extensions specify optional bodies if at all possible. We note that thererequest and its success responses is no defined way right now through MIME headersrecommended. This will allow both parties to indicate whether adetermine what body is mandatory or optional. This can be accomplished through a Require header, but a MIME parameter somehow seems more appropriatetypes are supported by their peers. Subsequent messaging between the peers would then only include body types that were indicated as being understood. 3.2 Security Security is an important component of any protocol. SIP extensions SHOULDshould consider how (or if) they affect usage of the general SIP security mechanisms. Most extensions should not require any new security capabilities beyond general purpose SIP. If they do, it is likely that the security mechanism has more general purpose application, and should be considered an extension in its own right. 3.3 Usage Guidelines All SIP extensions MUSTmust contain guidelines defining when the extension is to be used. For new headers, the extension MUSTmust define the request methods the header can appear in, and what responses it can be used in. It is RECOMMENDEDrecommended that this information be represented as a new row of Table 4 of RFC 2543 . The extension SHOULDshould specify which entities (UAC, UAS, proxy, redirect, registrar) are allowed to insert the header. 3.4 Syntactic Issues Extensions that define new methods SHOULDshould use all capitals for the method name. Method names SHOULDshould be less than 10 characters, and SHOULDshould attempt to convey the general meaning of the request. Extensions that define new headers SHOULDshould define a compact form representation if the non-compact header is more than four characters. Compact headers must be a single character. When all 26 characters are exhausted, new compact forms will no longer be defined. Header names SHOULDshould use ASCII characters. Header names are always case insensitive. Header values are generally case sensitive, with the exception of domain names which MUSTmust be case insensitive. Case sensitivity of parameters and values is a constant source of confusion. SIP extensions MUSTmust clearly indicate the case sensitivity or insensitivity of every parameter, value or field they define. In general, case sensitivity is preferred because of the reduced processing requirements. Extensions which contain freeform text MUSTmust allow that text to be UTF-8, as per the IETF policies on character set usage . This ensures that SIP remains an internationalized standard. As a general guideline, freeform text is never needed by programs in order to perform protocol processing. It is usually entered by and displayed to the user. If an extension uses a parameter which can contain UTF-8 encoded characters, and that extension requires a comparison to be made of this parameter to other parameters, the comparison MUSTshould be case sensitive. Case insensitive comparison rules for UTF-8 text are extremely complicated and are to be avoided. Extensions which make use of dates and times MUSTmust use the SIP-Date BNF defined in RFC 2543. No other date formats are allowed. Extensions which include network layer addresses SHOULDshould permit dotted quad IPv4 addresses, IPv6 addresses in the format described in , and domain names. Extensions which have headers containing URLs SHOULDshould allow any URI, not just SIP URLs. Headers SHOULDshould follow the standard formatting for SIP, defined as: header-name ":" # (value *( ";" parameter-name ["=" token] ) | ";" parameter-name ["=" quoted-string] )) Developers of extensions are strongly encouraged to allow for parameters in their headers, and to also define extension parameters for their headers. Headers that contain a list of URIs SHOULDshould follow the same syntax as the Contact header in SIP. Implementors are also encouraged to always wrap these URI in angle brackets "<" and ">". We have found this to be a frequently misimplemented feature. Beyond compact form, there is no need to define compressed versions of header values. Compression of SIP messages SHOULDshould be handled at lower layers, for example, using IP payload compression  or link layer compression. Syntax for headers is expressed in Augmented Backus-Naur Form. Extensions must make use of the primitive components defined in RFC2543 . If the construction for a BNF element is defined in another specification, it is recommended that the construction be referenced rather than copied. The reference should include both the document and section number. All BNF elements must be either defined or referenced. All tokens and quoted strings are separated by implicit linear white space. Linear white space, for better or worse, allows for line folding. Extensions cannot define new headers that use alternate linear white space rules. 3.5 Semantics, Semantics, Semantics Developers of protocols often get caught up in syntax issues, without spending enough time on semantics. The semantics of a protocol are far more important. SIP extensions MUSTmust clearly define the semantics of the extensions. Specifically, the extension MUSTmust specify the behaviors expected of a UAC, UAS and proxy in processing the extension. This is often best described by having separate sections for each of these three elements. Each section SHOULDshould step through the processing rules in temporal order of the most common messaging scenario. Processing rules generally specify actions to take (in terms of messages to send, variables to store, rules to follow) on receipt of messages and expiration of timers. If an action requires transmission of a message, the rule SHOULDshould outline requirements for insertion of headers or other information in the message. The extension SHOULDshould specify procedures to take in exceptional conditions. This usually includes receipt of messages that are not expected, expiration of timers that handle timeouts, and presence of headers in messages when they are not expected. 3.6 Examples Section Presence of sections in the extension giving examples of call flows and message formatting is RECOMMENDED.recommended. Extensions which define substantial new syntax SHOULDshould include examples of messages containing that syntax. Examples of message flows SHOULDshould be given to cover common cases and at least one failure or unusual case. For an example of how to construct a good examples section, see the message flows and message formatting defined in the Call Flows Example specification . Note that complete messages SHOULDshould be used. Be careful to include tags, Via headers, Content-Lengths, Record-Route and Route headers. 3.7 Overview Section Too often, extension documents dive into detailed syntax and semantics without giving a general overview of operation. This makes understanding of the extension harder. It is RECOMMENDEDrecommended that extensions have a protocol overview section which discusses the basic operation of the extension. Basic operation usually consists of the message flow, in temporal order, for the most common case covered by the extension. The most important processing rules for the elements in the call flow SHOULDshould be mentioned. Usage of the RFC 2119  terminology in the overview section is RECOMMENDED.recommended. 3.8 Additional Considerations for New Methods Extensions which define new methods SHOULDshould take into consideration, and discuss, the following issues: o Can it contain bodies? If so, what is the meaning of the presence of those bodies? What body types are allowed? o Can a transaction with this request method occur while another transaction, in the same and/or reverse direction, is in progress? o What headers are allowed in requests of this method? It is recommended that this information be presented through a column of Table 4 in RFC 2543 . o All SIP requests can generally be cancelled. However, an extension MAYmay mandate that a new method notcannot be cancelled. In either case, handling of CANCEL SHOULDshould be described. In particular, the rules a UAS should follow upon cancellation of an unanswered request SHOULDshould be described. o Can the request be sent within a call or not? In this context, within means that the request is sent with the same Call-ID, To and From field as an INVITE that was sent or received previously. For, example, the REGISTER method is not associated with a call, whereas the BYE method is. Note that the reliability mechanisms for all new methods MUSTmust be the same as for BYE. The delayed response feature of INVITE is only available in INVITE, never for new methods. This means requests with new SIP methods need to be responded to within short time periods (on the order of seconds). 3.9 Additional Considerations for New Headers or Header Parameters The most important issue for extensions that define new headers is backwards compatibility. See Section 3.1 for a discussion of the issues. The extension MUSTmust detail how backwards compatibility is addressed. It is often tempting to avoid creation of a new method by overloading an existing method through a header. Headers are not meant to fundamentally alter the meaning of the method of the request. A new header SHOULD NOTcannot change the basic semantic and processing rules of a method. 3.10 Additional Considerations for New Body Types Because SIP can run over UDP, extensions that specify the inclusion of large bodies are frowned upon. If at all possible, the content should be included indirectly through an http URL. Note that the presence of a body MUST NOTmust not change the nature of the message. That is, bodies cannot alter the state machinery associated with processing a request of a particular method or a response. Bodies enhance this processing by providing additional data. 4 Interactions with SIP Features We have observed that certain capabilities of SIP continually interact with extensions in unusual ways. Writers of extensions SHOULDshould consider the interactions of their extensions with these SIP capabilities, document any unusual interactions if they exist. The most common causes of problems are: Forking: Forking by far presents the most troublesome interactions with extensions. This is generally because it can cause (1) a single transmitted request to be received by an unknown number of UASs, and (2) a single request to have multiple responses. Tags: Tags are used to uniquely identify call legs. Their presence is neccesitated as a result of forking. They are an unfortunate exception to many SIP processing rules. Extensions should carefully consider their effect. CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in that they are exceptions to many of the general request processing rules. The main reason for this special status is that CANCEL and ACK are always associated with another request. New methods SHOULDshould consider the meaning of cancellation. New headers in INVITE requests SHOULDshould consider whether they also need to be included in ACK. Routing: The Route, Record-Route and Via headers are used to support message routing. New request methods SHOULDshould carefully consider how these headers are used. Stateless Proxies: SIP allows a proxy to be stateless. Stateless proxies are unable to retransmit messages and cannot execute certain services. Extensions which depend on some kind of proxy processing SHOULDshould consider how stateless proxies affect that processing. 5 Security Considerations The nature of this document is such that it does not introduce any new security considerations. 6 Changes since -00 o Added that SIPCompact form is appropriate for rendezvous applications not related to initiation.a single character. o Added the usage of registration for transfer is appropriate. o Mandated usage of the common form for headers. o Headers containing a list of URIs should be formatted like Contact.some notes on BNF usage. o Reference call flows document as an example of example call flows.Clarified extensions section. o Bodies can't change the semantics ofSIP is not a request.PSTN replacement. o Compression is done at lower layers,Do not withinincorporate general purpose, cross-application functions (like new key exchange protocols) into SIP. o SIPRequest URI is not an RPC protocol.used for routing o SIPHeterogeneity is the norm. o No longer using rfc2119 terminology, as it is not a control protocol.appropriate for BCP. 7 Authors Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue East Hanover, NJ 07936 email: email@example.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: firstname.lastname@example.org 8 Bibliography  M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999.  R. Droms, "Dynamic host configuration protocol," Request for Comments 2131, Internet Engineering Task Force, Mar. 1997.  J. Rosenberg and H. Schulzrinne, "The SIP supported header," Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in progress.  S. Donovan and J. Rosenberg, "SIP session timer," Internet Draft, Internet Engineering Task Force, Mar.Oct. 2000. Work in progress.  N. FreedM. Handley, H. Schulzrinne, E. Schooler, and N. Borenstein, "Multipurpose internet mail extensions (MIME) part two: Media types," Request for Comments 2046,J. Rosenberg, "SIP: Session initiation protocol," Internet Draft, Internet Engineering Task Force, Nov. 1996.Aug. 2000. Work in progress.  H. Alvestrand, "IETF policy on character sets and languages," Request for Comments 2277, Internet Engineering Task Force, Jan. 1998.  R. Hinden, B. Carpenter, and L. Masinter, "Format for literal IPv6 addresses in URL's," Request for Comments 2732, Internet Engineering Task Force, Dec. 1999.  A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload compression protocol (ipcomp)," Request for Comments 2393, Internet Engineering Task Force, Dec. 1998.  A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers,D. Willis, J. Rosenberg, K. Summers, and H. a.Schulzrinne, "SIP telephony call flow examples," Internet Draft, Internet Engineering Task Force, Mar.July 2000. Work in progress.  S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997.