RFC 2543
SIP: Session Initiation Protocol
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.
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.
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.
All media descriptions SHOULD contain "a=rtpmap" mappings from RTP
payload types to encodings.
This allows easier migration away from static payload
types.
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).
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
c=IN IP4 host.anywhere.com
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:
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
c=IN IP4 host.example.com
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
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.
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 indicated. 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 send-and-receive. 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 known.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
in the original invitation (or response), but the "c" destination addresses for the media streams to be put on hold are set to zero (0.0.0.0).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 empty.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.
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. "literal" 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".
*rule
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.
[rule]
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.
#rule
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.
; 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:
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
value.
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.
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
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
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 sip:user@company.com. 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="sip.udp.company.com",
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
"company.com". An address is found, so that client attempts
to contact a server at that address at port 5060.
E IANA Considerations
Section 4.4 describes a name space and mechanism for registering SIP options. Section 6.41 describes the name space for registering SIP warn-codes.
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 USA Email: mjh@aciri.org Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu Eve Schooler Computer Science Department 256-80 California Institute of Technology Pasadena, CA 91125 USA Email: schooler@cs.caltech.edu Jonathan Rosenberg Lucent Technologies, Bell Laboratories Rm. 4C-526 101 Crawfords Corner Road Holmdel, NJ 07733 USA Email: jdrosen@bell-labs.com
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 progress. [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.
[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.
[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 1997. [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. 1996.
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 English. 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.