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
(RFC2052 [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 RFC2052 [14]. The
results of the query or queries are merged together and
ordered based on priority. Then, the searching technique
outlined in RFC2052 [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 RFC2052 [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", RFC2205, October 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
a transport protocol for real-time applications", RFC1889,
Internet Engineering Task Force, Jan. 1996.
[4] Schulzrinne, H., Lanphier, R. and A. Rao, "Real time streaming
protocol (RTSP)", RFC2326, 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",
RFC2327, 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, RFC2119, 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", RFC2396, August 1998.
[13] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform resource
locators (URL)", RFC1738, December 1994.
[14] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC2052, October 1996.
[15] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC1035, Noveberm 1997.
[16] Hamilton, M. and R. Wright, "Use of DNS aliases for network
services", RFC2219, October 1997.
[17] Zimmerman, D., "The finger user information protocol", RFC1288,
December 1991.
[18] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
Zeilstra, "Referral whois (rwhois) protocol V1.5", RFC2167,
June 1997.
[19] Yeong, W., Howes, T. and S. Kille, "Lightweight directory access
protocol", RFC1777, 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", RFC1191,
November 1990.
[24] Crocker, D., "Standard for the format of ARPA internet text
messages", RFCSTD 11, RFC822, August 1982.
[25] Meyer, D., "Administratively scoped IP multicast", RFC2365,
July 1998.
[26] Schulzrinne, H., "RTP profile for audio and video conferences
with minimal control", RFC1890, January 1996
[27] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
recommendations for security", RFC1750, December 1994.
[28] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
scheme", RFC2368, July 1998.
[29] Braden, B., "Requirements for internet hosts - application and
support", STD 3, RFC1123, October 1989.
[30] Palme, J., "Common internet message headers", RFC2076, February
1997.
[31] Alvestrand, H., "IETF policy on character sets and languages",
RFC2277, 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", RFC1991, August 1996.
[34] Atkinson, R., "Security architecture for the internet protocol",
RFC2401, 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.