Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next  

RFC 2543

SIP: Session Initiation Protocol

Pages: 151
Group: ~perf-qos

Obsoleted by:  32613262326332643265
Part 6 of 6 – Pages 134 to 151
First   Prev   None

ToP   noToC   RFC2543 - Page 134   prevText
A Minimal Implementation

A.1 Client

   All clients MUST be able to generate the INVITE and ACK requests.
   Clients MUST generate and parse the Call-ID, Content-Length,
   Content-Type, CSeq, From and To headers. Clients MUST also parse the
   Require header. A minimal implementation MUST understand SDP (RFC
   2327, [6]). It MUST be able to recognize the status code classes 1
   through 6 and act accordingly.

   The following capability sets build on top of the minimal
   implementation described in the previous paragraph. In general, each
   capability listed below builds on the ones above it:

   Basic: A basic implementation adds support for the BYE method to
        allow the interruption of a pending call attempt. It includes a
        User-Agent header in its requests and indicates its preferred
        language in the Accept-Language header.

   Redirection: To support call forwarding, a client needs to be able to
        understand the Contact header, but only the SIP-URL part, not
        the parameters.

   Firewall-friendly: A firewall-friendly client understands the Route
        and Record-Route header fields and can be configured to use a
        local proxy for all outgoing requests.

   Negotiation: A client MUST be able to request the OPTIONS method and
        understand the 380 (Alternative Service) status and the Contact
        parameters to participate in terminal and media negotiation. It
        SHOULD be able to parse the Warning response header to provide
        useful feedback to the caller.

   Authentication: If a client wishes to invite callees that require
        caller authentication, it MUST be able to recognize the 401
        (Unauthorized) status code, MUST be able to generate the
        Authorization request header and MUST understand the WWW-
        Authenticate response header.

   If a client wishes to use proxies that require caller authentication,
   it MUST be able to recognize the 407 (Proxy Authentication Required)
   status code, MUST be able to generate the Proxy-Authorization request
   header and understand the Proxy-Authenticate response header.
ToP   noToC   RFC2543 - Page 135
A.2 Server

   A minimally compliant server implementation MUST understand the
   INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also
   understand CANCEL. It MUST parse and generate, as appropriate, the
   Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max-
   Forwards, Require, To and Via headers. It MUST echo the CSeq and
   Timestamp headers in the response. It SHOULD include the Server
   header in its responses.

A.3 Header Processing

   Table 6 lists the headers that different implementations support. UAC
   refers to a user-agent client (calling user agent), UAS to a user-
   agent server (called user-agent).

   The fields in the table have the following meaning. Type is as in
   Table 4 and 5. "-" indicates the field is not meaningful to this
   system (although it might be generated by it). "m" indicates the
   field MUST be understood. "b" indicates the field SHOULD be
   understood by a Basic implementation.  "r" indicates the field SHOULD
   be understood if the system claims to understand redirection. "a"
   indicates the field SHOULD be understood if the system claims to
   support authentication. "e" indicates the field SHOULD be understood
   if the system claims to support encryption. "o" indicates support of
   the field is purely optional. Headers whose support is optional for
   all implementations are not shown.
ToP   noToC   RFC2543 - Page 136
                        type  UAC  proxy  UAS  registrar
   Accept                R     -     o     m      m
   Accept-Encoding       R     -     -     m      m
   Accept-Language       R     -     b     b      b
   Allow                405    o     -     -      -
   Authorization         R     a     o     a      a
   Call-ID               g     m     m     m      m
   Content-Encoding      g     m     -     m      m
   Content-Length        g     m     m     m      m
   Content-Type          g     m     -     m      m
   CSeq                  g     m     m     m      m
   Encryption            g     e     -     e      e
   Expires               g     -     o     o      m
   From                  g     m     o     m      m
   Hide                  R     -     m     -      -
   Contact               R     -     -     -      m
   Contact               r     r     r     -      -
   Max-Forwards          R     -     b     -      -
   Proxy-Authenticate   407    a     -     -      -
   Proxy-Authorization   R     -     a     -      -
   Proxy-Require         R     -     m     -      -
   Require               R     m     -     m      m
   Response-Key          R     -     -     e      e
   Route                 R     -     m     -      -
   Timestamp             g     o     o     m      m
   To                    g     m     m     m      m
   Unsupported           r     b     b     -      -
   User-Agent            g     b     -     b      -
   Via                   g     m     m     m      m
   WWW-Authenticate     401    a     -     -      -

   Table 6: Header Field Processing Requirements

B Usage of the Session Description Protocol (SDP)

   This section describes the use of the Session Description Protocol
   (SDP) (RFC 2327 [6]).

B.1 Configuring Media Streams

   The caller and callee align their media descriptions so that the nth
   media stream ("m=" line) in the caller's session description
   corresponds to the nth media stream in the callee's description.
ToP   noToC   RFC2543 - Page 137
   All media descriptions SHOULD contain "a=rtpmap" mappings from RTP
   payload types to encodings.

        This allows easier migration away from static payload

   If the callee wants to neither send nor receive a stream offered by
   the caller, the callee sets the port number of that stream to zero in
   its media description.

        There currently is no other way than port zero for the
        callee to refuse a bidirectional stream offered by the
        caller. Both caller and callee need to be aware what media
        tools are to be started.

   For example, assume that the caller Alice has included the following
   description in her INVITE request. It includes an audio stream and
   two bidirectional video streams, using H.261 (payload type 31) and
   MPEG (payload type 32).

   o=alice 2890844526 2890844526 IN IP4
   c=IN IP4
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000

   The callee, Bob, does not want to receive or send the first video
   stream, so it returns the media description below:

   o=bob 2890844730 2890844730 IN IP4
   c=IN IP4
   m=audio 47920 RTP/AVP 0 1
   a=rtpmap:0 PCMU/8000
   a=rtpmap:1 1016/8000
   m=video 0 RTP/AVP 31
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000
ToP   noToC   RFC2543 - Page 138
B.2 Setting SDP Values for Unicast

   If a session description from a caller contains a media stream which
   is listed as send (receive) only, it means that the caller is only
   willing to send (receive) this stream, not receive (send). The same
   is true for the callee.

   For receive-only and send-or-receive streams, the port number and
   address in the session description indicate where the media stream
   should be sent to by the recipient of the session description, either
   caller or callee. For send-only streams, the address and port number
   have no significance and SHOULD be set to zero.

   The list of payload types for each media stream conveys two pieces of
   information, namely the set of codecs that the caller or callee is
   capable of sending or receiving, and the RTP payload type numbers
   used to identify those codecs. For receive-only or send-and-receive
   media streams, a caller SHOULD list all of the codecs it is capable
   of supporting in the session description in an INVITE or ACK. For
   send-only streams, the caller SHOULD indicate only those it wishes to
   send for this session. For receive-only streams, the payload type
   numbers indicate the value of the payload type field in RTP packets
   the caller is expecting to receive for that codec type. For send-only
   streams, the payload type numbers indicate the value of the payload
   type field in RTP packets the caller is planning to send for that
   codec type.  For send-and-receive streams, the payload type numbers
   indicate the value of the payload type field the caller expects to
   both send and receive.

   If a media stream is listed as receive-only by the caller, the callee
   lists, in the response, those codecs it intends to use from among the
   ones listed in the request. If a media stream is listed as send-only
   by the caller, the callee lists, in the response, those codecs it is
   willing to receive among the ones listed in the the request. If the
   media stream is listed as both send and receive, the callee lists
   those codecs it is capable of sending or receiving among the ones
   listed by the caller in the INVITE. The actual payload type numbers
   in the callee's session description corresponding to a particular
   codec MUST be the same as the caller's session description.

   If caller and callee have no media formats in common for a particular
   stream, the callee MUST return a session description containing the
   particular "m=" line, but with the port number set to zero, and no
   payload types listed.

   If there are no media formats in common for all streams, the callee
   SHOULD return a 400 response, with a 304 Warning header field.
ToP   noToC   RFC2543 - Page 139
B.3 Multicast Operation

   The interpretation of send-only and receive-only for multicast media
   sessions differs from that for unicast sessions. For multicast,
   send-only means that the recipient of the session description (caller
   or callee) SHOULD only send media streams to the address and port
   indicated. Receive-only means that the recipient of the session
   description SHOULD only receive media on the address and port

   For multicast, receive and send multicast addresses are the same and
   all parties use the same port numbers to receive media data. If the
   session description provided by the caller is acceptable to the
   callee, the callee can choose not to include a session description or
   MAY echo the description in the response.

   A callee MAY, in the response, return a session description with some
   of the payload types removed, or port numbers set to zero (but no
   other value). This indicates to the caller that the callee does not
   support the given stream or media types which were removed. A callee
   MUST NOT change whether a given stream is send-only, receive-only, or

   If a callee does not support multicast at all, it SHOULD return a 400
   status response and include a 330 Warning.

B.4 Delayed Media Streams

   In some cases, a caller may not know the set of media formats which
   it can support at the time it would like to issue an invitation. This
   is the case when the caller is actually a gateway to another protocol
   which performs media format negotiation after call setup. When this
   occurs, a caller MAY issue an INVITE with a session description that
   contains no media lines. The callee SHOULD interpret this to mean
   that the caller wishes to participate in a multimedia session
   described by the session description, but that the media streams are
   not yet known. The callee SHOULD return a session description
   indicating the streams and media formats it is willing to support,
   however. The caller MAY update the session description either in the
   ACK request or in a re-INVITE at a later time, once the streams are

B.5 Putting Media Streams on Hold

   If a party in a call wants to put the other party "on hold", i.e.,
   request that it temporarily stops sending one or more media streams,
   a party re-invites the other by sending an INVITE request with a
   modified session description. The session description is the same as
ToP   noToC   RFC2543 - Page 140
   in the original invitation (or response), but the "c" destination
   addresses for the media streams to be put on hold are set to zero

B.6 Subject and SDP "s=" Line

   The SDP "s=" line and the SIP Subject header field have different
   meanings when inviting to a multicast session. The session
   description line describes the subject of the multicast session,
   while the SIP Subject header field describes the reason for the
   invitation. The example in Section 16.2 illustrates this point. For
   invitations to two-party sessions, the SDP "s=" line MAY be left

B.7 The SDP "o=" Line

   The "o=" line is not strictly necessary for two-party sessions, but
   MUST be present to allow re-use of SDP-based tools.
ToP   noToC   RFC2543 - Page 141
C Summary of Augmented BNF

   All of the mechanisms specified in this document are described in
   both prose and an augmented Backus-Naur Form (BNF) similar to that
   used by RFC 822 [9]. Implementors will need to be familiar with the
   notation in order to understand this specification. The augmented BNF
   includes the following constructs:

        name  =  definition

   The name of a rule is simply the name itself (without any enclosing
   "<" and ">") and is separated from its definition by the equal "="
   character. White space is only significant in that indentation of
   continuation lines is used to indicate a rule definition that spans
   more than one line. Certain basic rules are in uppercase, such as SP,
   LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within
   definitions whenever their presence will facilitate discerning the
   use of rule names.


   Quotation marks surround literal text. Unless stated otherwise, the
   text is case-insensitive.

   rule1 | rule2

   Elements separated by a bar ("|") are alternatives, e.g., "yes | no"
   will accept yes or no.

   (rule1 rule2)

   Elements enclosed in parentheses are treated as a single element.
   Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo
   elem" and "elem bar elem".
ToP   noToC   RFC2543 - Page 142

   The character "*" preceding an element indicates repetition. The full
   form is "<n>*<m>element" indicating at least <n> and at most <m>
   occurrences of element. Default values are 0 and infinity so that
   "*(element)" allows any number, including zero; "1*element" requires
   at least one; and "1*2element" allows one or two.


   Square brackets enclose optional elements; "[foo bar]" is equivalent
   to "*1(foo bar)".

   N rule

   Specific repetition: "<n>(element)" is equivalent to
   "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
   Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
   alphabetic characters.


   A construct "#" is defined, similar to "*", for defining lists of
   elements. The full form is "<n>#<m> element" indicating at least <n>
   and at most <m> elements, each separated by one or more commas (",")
   and OPTIONAL linear white space (LWS). This makes the usual form of
   lists very easy; a rule such as

           ( *LWS element *( *LWS "," *LWS element ))

   can be shown as 1# element. Wherever this construct is used, null
   elements are allowed, but do not contribute to the count of elements
   present. That is, "(element), , (element)" is permitted, but counts
   as only two elements. Therefore, where at least one element is
   required, at least one non-null element MUST be present. Default
   values are 0 and infinity so that "#element" allows any number,
   including zero; "1#element" requires at least one; and "1#2element"
   allows one or two.
ToP   noToC   RFC2543 - Page 143
   ; comment

   A semi-colon, set off some distance to the right of rule text, starts
   a comment that continues to the end of line. This is a simple way of
   including useful notes in parallel with the specifications.

   implied *LWS

   The grammar described by this specification is word-based. Except
   where noted otherwise, linear white space (LWS) can be included
   between any two adjacent words (token or quoted-string), and between
   adjacent tokens and separators, without changing the interpretation
   of a field. At least one delimiter (LWS and/or separators) MUST exist
   between any two tokens (for the definition of "token" below), since
   they would otherwise be interpreted as a single token.

C.1 Basic Rules

   The following rules are used throughout this specification to
   describe basic parsing constructs. The US-ASCII coded character set
   is defined by ANSI X3.4-1986.

        OCTET     =  <any 8-bit sequence of data>
        CHAR      =  <any US-ASCII character (octets 0 - 127)>
        upalpha   =  "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
                     "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
                     "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
        lowalpha  =  "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
                     "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
                     "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
        alpha     =  lowalpha | upalpha
        digit     =  "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"
        alphanum  =  alpha | digit
        CTL       =  <any US-ASCII control character
                     (octets 0 -- 31) and DEL (127)>
        CR        =  %d13 ; US-ASCII CR, carriage return character
        LF        =  %d10 ; US-ASCII LF, line feed character
        SP        =  %d32 ; US-ASCII SP, space character
        HT        =  %d09 ; US-ASCII HT, horizontal tab character
        CRLF      =  CR LF ; typically the end of a line

   The following are defined in RFC 2396 [12] for the SIP URI:
ToP   noToC   RFC2543 - Page 144
        unreserved  =  alphanum | mark
        mark        =  "-" | "_" | "." | "!" | "~" | "*" | "'"
                   |   "(" | ")"
        escaped     =  "%" hex hex

   SIP header field values can be folded onto multiple lines if the
   continuation line begins with a space or horizontal tab. All linear
   white space, including folding, has the same semantics as SP. A
   recipient MAY replace any linear white space with a single SP before
   interpreting the field value or forwarding the message downstream.

        LWS  =  [CRLF] 1*( SP | HT ) ; linear whitespace

   The TEXT-UTF8 rule is only used for descriptive field contents and
   values that are not intended to be interpreted by the message parser.
   Words of *TEXT-UTF8 contain characters from the UTF-8 character set
   (RFC 2279 [21]). In this regard, SIP differs from HTTP, which uses
   the ISO 8859-1 character set.

        TEXT-UTF8  =  <any UTF-8 character encoding, except CTLs,
                      but including LWS>

   A CRLF is allowed in the definition of TEXT-UTF8 only as part of a
   header field continuation. It is expected that the folding LWS will
   be replaced with a single SP before interpretation of the TEXT-UTF8

   Hexadecimal numeric characters are used in several protocol elements.

        hex  =  "A" | "B" | "C" | "D" | "E" | "F"
                | "a" | "b" | "c" | "d" | "e" | "f" | digit

   Many SIP header field values consist of words separated by LWS or
   special characters. These special characters MUST be in a quoted
   string to be used within a parameter value.
ToP   noToC   RFC2543 - Page 145
        token       =  1*< any CHAR  except CTL's  or separators>
        separators  =  "(" | ")" | "<" | ">" | "@" |
                       "," | ";" | ":" | "\" | <"> |
                       "/" | "[" | "]" | "?" | "=" |
                       "{" | "}" | SP | HT

   Comments can be included in some SIP header fields by surrounding the
   comment text with parentheses. Comments are only allowed in fields
   containing "comment" as part of their field value definition. In all
   other fields, parentheses are considered part of the field value.

        comment  =  "(" *(ctext | quoted-pair | comment) ")"
        ctext    =  < any TEXT-UTF8  excluding "("  and ")">

   A string of text is parsed as a single word if it is quoted using
   double-quote marks.

        quoted-string  =  ( <"> *(qdtext | quoted-pair ) <"> )
        qdtext         =  <any TEXT-UTF8 except <">>

   The backslash character ("\") MAY be used as a single-character
   quoting mechanism only within quoted-string and comment constructs.

        quoted-pair  =  " \ " CHAR
ToP   noToC   RFC2543 - Page 146
D Using SRV DNS Records

   The following procedure is experimental and relies on DNS SRV records
   (RFC 2052 [14]). The steps listed below are used in place of the two
   steps in section 1.4.2.

   If a step elicits no addresses, the client continues to the next
   step.  However if a step elicits one or more addresses, but no SIP
   server at any of those addresses responds, then the client concludes
   the server is down and doesn't continue on to the next step.

   When SRV records are to be used, the protocol to use when querying
   for the SRV record is "sip". SRV records contain port numbers for
   servers, in addition to IP addresses; the client always uses this
   port number when contacting the SIP server. Otherwise, the port
   number in the SIP URI is used, if present. If there is no port number
   in the URI, the default port, 5060, is used.

        1.   If the host portion of the Request-URI is an IP address,
             the client contacts the server at the given address. If the
             host portion of the Request-URI is not an IP address, the
             client proceeds to the next step.

        2.   The Request-URI is examined. If it contains an explicit
             port number, the next two steps are skipped.

        3.   The Request-URI is examined. If it does not specify a
             protocol (TCP or UDP), the client queries the name server
             for SRV records for both UDP (if supported by the client)
             and TCP (if supported by the client) SIP servers. The
             format of these queries is defined in RFC 2052 [14]. The
             results of the query or queries are merged together and
             ordered based on priority. Then, the searching technique
             outlined in RFC 2052 [14] is used to select servers in
             order.  If DNS doesn't return any records, the user goes to
             the last step.  Otherwise, the user attempts to contact
             each server in the order listed.  If no server is
             contacted, the user gives up.

        4.   If the Request-URI specifies a protocol (TCP or UDP) that
             is supported by the client, the client queries the name
             server for SRV records for SIP servers of that protocol
             type only. If the client does not support the protocol
             specified in the Request-URI, it gives up. The searching
             technique outlined in RFC 2052 [14] is used to select
             servers from the DNS response in order. If DNS doesn't
ToP   noToC   RFC2543 - Page 147
             return any records, the user goes to the last step.
             Otherwise, the user attempts to contact each server in the
             order listed. If no server is contacted, the user gives up.

        5.   The client queries the name server for address records for
             the host portion of the Request-URI. If there were no
             address records, the client stops, as it has been unable to
             locate a server. By address record, we mean A RR's, AAAA
             RR's, or their most modern equivalent.

   A client MAY cache a successful DNS query result. A successful query
   is one which contained records in the answer, and a server was
   contacted at one of the addresses from the answer. When the client
   wishes to send a request to the same host, it starts the search as if
   it had just received this answer from the name server. The server
   uses the procedures specified in RFC1035 [15] regarding cache
   invalidation when the time-to-live of the DNS result expires. If the
   client does not find a SIP server among the addresses listed in the
   cached answer, it starts the search at the beginning of the sequence
   described above.

   For example, consider a client that wishes to send a SIP request. The
   Request-URI for the destination is  The client
   only supports UDP. It would follow these steps:

        1.   The host portion is not an IP address, so the client goes
             to step 2 above.

        2.   The client does a DNS query of QNAME="",
             QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it
             omits the TCP query. There were no addresses in the DNS
             response, so the client goes to the next step.

        3.   The client does a DNS query for A records for
             "". An address is found, so that client attempts
             to contact a server at that address at port 5060.
ToP   noToC   RFC2543 - Page 148
E IANA Considerations

   Section 4.4 describes a name space and mechanism for registering SIP

   Section 6.41 describes the name space for registering SIP warn-codes.
ToP   noToC   RFC2543 - Page 149
F Acknowledgments

   We wish to thank the members of the IETF MMUSIC WG for their comments
   and suggestions. Detailed comments were provided by Anders
   Kristensen, Jim Buller, Dave Devanathan, Yaron Goland, Christian
   Huitema, Gadi Karmi, Jonathan Lennox, Keith Moore, Vern Paxson, Moshe
   J. Sambol, and Eric Tremblay.

   This work is based, inter alia, on [37,38].

G Authors' Addresses

   Mark Handley
   AT&T Center for Internet Research at ISCI (ACIRI)
   1947 Center St., Suite 600
   Berkeley, CA 94704-119

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027

   Eve Schooler
   Computer Science Department 256-80
   California Institute of Technology
   Pasadena, CA 91125

   Jonathan Rosenberg
   Lucent Technologies, Bell Laboratories
   Rm. 4C-526
   101 Crawfords Corner Road
   Holmdel, NJ 07733
ToP   noToC   RFC2543 - Page 150
H Bibliography

   [1] Pandya, R., "Emerging mobile and personal communication systems,"
       IEEE Communications Magazine , vol. 33, pp. 44--52, June 1995.

   [2] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
       "Resource ReSerVation protocol (RSVP) -- version 1 functional
       specification", RFC 2205, October 1997.

   [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       a transport protocol for real-time applications", RFC 1889,
       Internet Engineering Task Force, Jan. 1996.

   [4] Schulzrinne, H., Lanphier, R. and A. Rao, "Real time streaming
       protocol (RTSP)", RFC 2326, April 1998.

   [5] Handley, M., "SAP: Session announcement protocol," Internet
       Draft, Internet Engineering Task Force, Nov. 1996.  Work in

   [6] Handley, M. and V. Jacobson, "SDP: session description protocol",
       RFC 2327, April 1998.

   [7] International Telecommunication Union, "Visual telephone systems
       and equipment for local area networks which provide a non-
       guaranteed quality of service," Recommendation H.323,
       Telecommunication Standardization Sector of ITU, Geneva,
       Switzerland, May 1996.

   [8] International Telecommunication Union, "Control protocol for
       multimedia communication," Recommendation H.245,
       Telecommunication Standardization Sector of ITU, Geneva,
       Switzerland, Feb. 1998.

   [9] International Telecommunication Union, "Media stream
       packetization and synchronization on non-guaranteed quality of
       service LANs," Recommendation H.225.0, Telecommunication
       Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996.

   [10] Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", BCP 14,  RFC 2119, Mardch 1997.

   [11] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
        Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1", RFC
        2068, January 1997.

   [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform resource
        identifiers (URI): generic syntax", RFC 2396, August 1998.
ToP   noToC   RFC2543 - Page 151
   [13] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform resource
        locators (URL)", RFC 1738, December 1994.

   [14] Gulbrandsen, A.  and P. Vixie, "A DNS RR for specifying the
        location of services (DNS SRV)", RFC 2052, October 1996.

   [15] Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, Noveberm 1997.

   [16] Hamilton, M. and R. Wright, "Use of DNS aliases for network
        services", RFC 2219, October 1997.

   [17] Zimmerman, D., "The finger user information protocol", RFC 1288,
        December 1991.

   [18] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
        Zeilstra, "Referral whois (rwhois) protocol V1.5", RFC 2167,
        June 1997.

   [19] Yeong, W., Howes, T. and S. Kille, "Lightweight directory access
        protocol", RFC 1777, March 1995.

   [20] Schooler, E., "A multicast user directory service for
        synchronous rendezvous," Master's Thesis CS-TR-96-18, Department
        of Computer Science, California Institute of Technology,
        Pasadena, California, Aug. 1996.

   [21] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

   [22] Stevens, W., TCP/IP illustrated: the protocols , vol. 1.
        Reading, Massachusetts: Addison-Wesley, 1994.

   [23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
        November 1990.

   [24] Crocker, D., "Standard for the format of ARPA internet text
        messages", RFC STD 11, RFC 822, August 1982.

   [25] Meyer, D., "Administratively scoped IP multicast", RFC 2365,
        July 1998.

   [26] Schulzrinne, H., "RTP profile for audio and video conferences
        with minimal control", RFC 1890, January 1996

   [27] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
        recommendations for security", RFC 1750, December 1994.
ToP   noToC   RFC2543 - Page 152
   [28] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
        scheme", RFC 2368, July 1998.

   [29] Braden, B., "Requirements for internet hosts - application and
        support", STD 3, RFC 1123, October 1989.

   [30] Palme, J., "Common internet message headers", RFC 2076, February

   [31] Alvestrand, H., "IETF policy on character sets and languages",
        RFC 2277, January 1998.

   [32] Elkins, M., "MIME security with pretty good privacy (PGP)", RFC
        2015, October 1996.

   [33] Atkins, D., Stallings, W. and P. Zimmermann, "PGP message
        exchange formats", RFC 1991, August 1996.

   [34] Atkinson, R., "Security architecture for the internet protocol",
        RFC 2401, November 1998.

   [35] Allen, C. and T. Dierks, "The TLS protocol version 1.0," RFC
        2246, January 1999.

   [36] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
        Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication:
        Basic and digest access authentication," Internet Draft,
        Internet Engineering Task Force, Sept.  1998.  Work in progress.

   [37] Schooler, E., "Case study: multimedia conference control in a
        packet-switched teleconferencing system," Journal of
        Internetworking:  Research and Experience , vol. 4, pp. 99--120,
        June 1993.  ISI reprint series ISI/RS-93-359.

   [38] Schulzrinne, H., "Personal mobility for multimedia services in
        the Internet," in European Workshop on Interactive Distributed
        Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar.
ToP   noToC   RFC2543 - Page 153
Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an