Internet Draft
Session Initiation Protocol James Kempf
INTERNET DRAFT Sun Microsystems
Feburary 8, 2000 Jonathan Rosenberg
dynamicsoft
Finding a SIP Server With SLP
draft-kempf-sip-findsrv-00.txt
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 work-
ing documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also dis-
tribute 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 refer-
ence 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) allows a user to communicate
with a local SIP proxy and registrar, primarily for registration
services and the execution of certain features. Currently, SIP
allows for discovery of these servers through multicast or
through static configuration. In many cases, it may be more
useful for a SIP client to discover local SIP servers based
on features supported by those servers. In this document, an alternate
technique is specified based on Service Location Protocol (SLP).
The document contains a short description of how to use SLP for service
discovery, and a SIP service type template. The service type template
defines the attributes and service URL for a SIP server advertisement,
suitable for SIP clients to discover.
1. Introduction
Kempf, Rosenberg expires August 2000 [Page 1]
INTERNET DRAFT Feburary 2000
The Session Initiation Protocol (SIP) [1] allows a user to communicate
with a local SIP proxy and registrar. The server provides registration
services and the execution of certain features. SIP allows for the
discovery of servers through multicast and static configuration. The
multicast mechanism allows a SIP client, or UAC, to send a REGISTER
message to a well-known SIP multicast address. A registrar that is wil-
ling to serve the user can then answer the request. Similarly, a UAC
can send an INVITE message via multicast in order to determine its
local outbound proxy.
This approach is limiting, however, if many SIP servers are distributed
throughout the domain. Different servers may have differing capabili-
ties. Some technique is required whereby a UAC can find a server that
supports the particular characteristics it needs.
In this document, we describe how to use Service Location Protocol
(SLP)[2] for configuring a UAC with a SIP proxy or registrar server.
SLP is a new protocol for dynamically discovering contact information
for a service. SLP is specifically designed for co-operatively managed
networks, and not for the Internet, so the techniques described in
RFC 2543 would still apply if the SIP client is required to directly
connect with a server on the Internet.
Since SLP supports querying for services based on attributes, using
SLP allows a SIP client to find a locally available SIP server
meeting its requirements with regard to transport protocol and
other characteristics. Querying by characteristic reduces the
amount of network traffic involved in discovering a server, and the
amount of computation the client is required to perform before
starting the SIP session. Section 8 contains a service
type template [3] describing the attributes advertised by a SIP
server and the format of the service URL returned as a result of an
SLP query.
2. Notation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [5].
3. Terminology
We reproduce here some SLP terminology from RFC 2608 for readers
unfamilar with SLP.
User Agent (SLP UA)- A process working on the user's behalf to
establish contact with some service. The SLP UA retrieves service
information from the Service Agents, using multicast, or
Kempf, Rosenberg expires August 2000 [Page 2]
INTERNET DRAFT Feburary 2000
Directory Agents, using unicast.
Service Agent(SA)- A process working on behalf of one or more
services to advertise the services and their capabilites. The
SA listens for multicast SLP UA requests, and registers its
advertisements with DAs if any DAs are available.
Directory Agent(DA)- A process which collects service
advertisements. A DA acts as a cache to consolidate service
advertisements so a SLP UA can use unicast instead of multicast to
obtain service advertisements.
Scope - A set of services, typically making up a logical
administrative group.
Service Advertisement - A URL, attributes, and a lifetime
(indicating how long the advertisement is valid), providing
service access information and capabilities description for a
particular service.
4. Using SLP for SIP Server Discovery
SLP provides the framework in which a SIP client finds an appropri-
ate local registrar or proxy/redirect server. Here is a description of
how an SIP client finds its server using SLP:
1. The SIP server implements an SLP SA while the UAC
implements an SLP UA.
2. The SIP SA constructs a service advertisment consisting of a
service URL, attributes and a lifetime. The URL has an
appropriate service type, either "service:sip:proxy" if the
server is a proxy/redirect server or "service:sip:registrar"
if the server is a registrar server, and attributes defined
according to the template in Section 8.
3. When the SIP client requires contact information for a SIP
server, the SLP UA either contacts the DA using unicast or the SA
using multicast. The SLP UA includes a query based on the attributes
to indicate the characteristics of the server it requires.
4. Once the SLP UA has the contact information for the SIP server,
the UAC can either send a registration (if the UAC is seeking a
registrar server) or an INVITE (if the UAC is seeking a local
outbound proxy/redirect server). The service URL returned from
the SLP query includes the IP address or host name, and,
optionally, the port number of the SIP server. If the port
number is not included, the SIP client uses the IANA-assigned
Kempf, Rosenberg expires August 2000 [Page 3]
INTERNET DRAFT Feburary 2000
SIP port, 5060.
This procedure is exactly the same for any client/server pair imple-
menting SLP and is not specific to SIP.
SLP provides a number of advantages over SIP-specific multicast
and static configuration. The major advantage of SLP is that
clients can specify the attributes describing the desired server.
The UAC can find a server that supports exactly the features
it needs without requiring every server to support all SIP features.
With SLP, an enterprise can support a heterogeneous mix of
servers and UACs can find those that best suit their needs.
Additionally, SLP contains a number of scaling mechanisms (DAs,
scopes), that facilitate deployment in large enterprise networks, as
well as in smaller networks.
5. Scalability
SLP contains a mechanism, called scopes, for grouping service
advertisements. For example, a network administrator could arrange
for all users in the Marketing Department to share access to a col-
lection of service advertisements by putting their SLP UAs, SAs, and
DAs into the same scope. Unless another deparment is in the same
scope, their SLP UAs, SAs and DAs would not have access to service
advertisements. Scopes don't control access to the services
themselves, however, just to the advertisements. Scope configuration
is not required, because SLP specifies a default scope that is used
if no other scope is available. Scopes are one important scalability
mechanism included in the SLP design.
The other scaling mechanism is DAs. In small/home office networks, SLP
UAs use multicast to contact SLP SAs. In larger, enterprise networks,
the network can be configured with DAs to cache advertisements
and reduce the amount of multicast traffic on the network. Again, DAs
are not a required part of SLP but can be configured if necessary.
Scope and DA information can be preconfigured for SLP agents by
including them in the DHCP option record for SLP [4]. This allows the
SLP agents to be configured without any local information. DHCP con-
figuration is not necessary, however. SLP UAs can determine their scope
and DA information dynamically, and DAs and SAs use the default
scope if no other scope is configured.
6. Finding the Right Proxy for an Incoming Call
Without SLP, SIP servers are typically organized into a hierarchy
according to the hierarchy of DNS domain names. For example, Acme, Inc.
has one top level domain and three second level domains, corresponding
Kempf, Rosenberg expires August 2000 [Page 4]
INTERNET DRAFT Feburary 2000
to the Sales, Marketing, and Engineering departments. The domain names
are:
acme.com - Top level domain
sales.acme.com - Sales department
mkt.acme.com - Marketing department
eng.acme.com - Engineering department
In a statically configured SIP system, each domain has one or
several proxy servers per domain. The names of these servers are
available from DNS, either through resolving a name directly or through
using the DNS SRV record. If multiple proxies are configured to support
a single domain (using DNS load balancing techniques), all of those
servers contain the registration for a user. This is accomplished
through some back end replication protocol, or through SIP multicast
registrations.
A call coming through the proxy server for the top level domain is
resolved by determining in which domain the called party is
located. The request is proxied to any proxy server in the called
party's domain. In our previous example, if a call comes in for Joe
User in the Engineering department, the Acme top level proxy can
easily determine which which proxy to use by looking up the user in
some corporate directory, as in the following figure:
|
| joe.user@acme.com
|
|
v
+----------------+ +------------------+
| | | |
| acme.com proxy | <----> | Backend Database |
| | | |
+----------------+ +------------------+
^
|
v
+--------------+ +--------------+ +----------------+
| | | | | |
| mkt.acme.com | | eng.acme.com | | sales.acme.com |
| registrar | | registrar | | registrar |
| | | | | |
+--------------+ | joe.user | +----------------+
+--------------+
Kempf, Rosenberg expires August 2000 [Page 5]
INTERNET DRAFT Feburary 2000
If SLP is in use, a SIP system can be configured so that different
registrar servers in the same domain support different capabilities.
Thus, from the example, the Engineering domain might contain one
registrar server that supports CPL [6] processing and another that
supports CGI processing.
A UAC can use SLP to discover a SIP registrar server supporting
a particular set of capabilities that it needs. For example, suppose
that Joe User wants to upload a CPL program to his SIP registrar.
Joe can specify that his UAC use SLP to find a registrar that supports
CPL [7] and register with it. As a consequence, the registration will
not be available to other registrars/proxies.
>From the previous figure, the proxy server for acme.com can't simply
use a static back end database to determine the next hop proxy,
because a dynamically chosen one has a registration for the user:
|
| joe.user@acme.com
|
|
v
+----------------+
| |
| acme.com proxy |
| |
+----------------+
?????
+------------------+ +------------------+
| | | |
| cgi.eng.acme.com | | cpl.eng.acme.com |
| registrar | | registrar |
| | | |
+------------------+ | joe.user |
+------------------+
There are two ways this problem can be handled:
1. The top level proxy server can use SIP "forking"
to try more than one next hop proxy server at once.
Whichever proxy has a registration for the user will
redirect or proxy there, and all others will return a 404
Not Found. This approach has the drawback of requiring the
Kempf, Rosenberg expires August 2000 [Page 6]
INTERNET DRAFT Feburary 2000
top level proxy to have a list of all possible proxies the user
may have registered at. It could discover these using SLP (see
Section 7 on non-SIP-UAs as SLP UAs), or be configured with
them.
2. The top level proxy server multicasts the invitation
to the SIP multicast address. The registrar with the
registration will proxy the call to the user. All others
will not respond. This approach has the advantage of requiring
less configuration.
7. SIP Servers as SLP UAs
Although SLP is primarily of interest by UACs for finding servers
having particular characteristics, it may also be used by SIP
servers for finding other SIP servers. As an example, in the previous
section, the top level acme.com SIP proxy server could use SLP to
locate the registrar servers in the eng domain. Although this does
not help in finding which registrar server has the registration,
it does allow the network of SIP servers to autoconfigure, in the
event a server goes down or a new one is added, without requiring
DNS updates or changing static configurations.
In general, a SIP server locating other SIP servers does
not include particular attributes in its query, other than the
"transport" attribute that is required in every query. And,
since SLP is only of use on cooperatively managed networks,
a SIP proxy server in one top level domain can't use SLP over
the Internet to locate the proxy in another. But a server MAY
include a query if it requires that the contacted servers
support particular characteristics. An example here is IP-level
security.
8. The SIP Service Type Template
SIP defines two different kinds of servers: registrars and proxy/
redirect servers. The features of both are different enough that
separate service type templates are required. We define an abstract
service type [3], with a concrete service type for the two
different kinds of servers.
8.1 SIP Abstract Service Type
Name of submitters: James Kempf
Jonathan Rosenberg
Language of service template: en
Security Considerations:
Kempf, Rosenberg expires August 2000 [Page 7]
INTERNET DRAFT Feburary 2000
SIP clients can use Service Location Protocol to find SIP servers
having particular security characteristics. If secure access to
such information is required, SLP security should be used.
Template text:
----------------------template begins here ------------------------
template-type = sip
template-version = 0.0
template-description=
The abstract service:sip type provides advertisements for clients
seeing Session Initiation Protocol (SIP) service. Concrete types
specialize the service:sip type for proxy/redirect and
registrar servers.
template-url-syntax= transport-attr-list
transport-attr-list = ';transport=udp' / ';transport=tcp' /
';transport=udp,tcp'
;The SIP service URL includes the transport protocol or
;protocols that the server supports. While the client must include
;the protocol type in the query and therefore does not need this
;information, the transport protocol attribute is included in
;the URL in case the client passes the URL along to a third
;party, for example, by way of a SIP Request-URI.
;An example SIP service URL (for a proxy server) is:
; service:sip:proxy://telsrv:2021;transport=udp.
;
transport = STRING X L M
udp
#Transport protocol used to contact the server. Servers can support
#UDP, TCP, or both. This attribute is REQUIRED in every query.
udp,tcp
domain = STRING M L O
#The name of the domain represented by the server.
ip-security-mechanisms = STRING M L O
#IP-level security mechanisms supported by the server.
#Allowed values are:
#
# ipsec - The server supports IP level security (IPSEC).
# tls - The server supports transport level security (TLS).
#
ipsec,tls
Kempf, Rosenberg expires August 2000 [Page 8]
INTERNET DRAFT Feburary 2000
sip-security-mechanisms = STRING M L O
#SIP-level security mechanisms supported by the server.
#Allowed values are:
#
# basic - The server supports basic authentication.
# digest - The server supports digest authentication.
# pgp - The server supports PGP authentication.
#
basic,digest,pgp
options = STRING M L O
#A collection of SIP option tags supported by the server. The tags
#are appropriate for inclusion in the REQUIRE or OPTIONS
#SIP request.
extensions = STRING M L O
#A list of extensions supported by the server. UACs use
#this attribute to identify whether a server supports
#a particular extension.
----------------------template ends here --------------------------
8.2 SIP Proxy/Redirect Concrete Service Type
Name of submitters: James Kempf
Jonathan Rosenberg
Language of service template: en
Security Considerations:
SIP clients can use Service Location Protocol to find SIP proxy/redirect
servers having particular security characteristics. If secure access to
such information is required, SLP security should be used.
Template text:
----------------------template begins here ------------------------
template-type = sip:proxy
template-version = 0.0
template-description=
The service:sip:proxy type provides advertisements for clients
seeking Session Initiation Protocol (SIP) proxy/redirect servers.
template-url-syntax = ;inherited from abstract type.
features = STRING M L O
#A list of features supported by the server. Allowed values are:
Kempf, Rosenberg expires August 2000 [Page 9]
INTERNET DRAFT Feburary 2000
#
# recursion - The server can recursively try addresses returned to
# it in a redirect request.
# forking - The proxy may fork off multiple requests in response to
# a client request.
# stateful - The proxy remembers incoming request that generated
# outgoing requests and the corresponding outgoing
# requests.
#
recursion,forking,stateful
caller-preferences = BOOLEAN O
#True if the server supports caller preferences.
handles-e.164-addresses = BOOLEAN O
#True if the server handles E.164 (telephone number)
#addresses. An example is:
# tel:5551234
----------------------template ends here --------------------------
8.3 SIP Registrar Concrete Service Type
Name of submitters: James Kempf
Jonathan Rosenberg
Language of service template: en
Security Considerations:
SIP clients can use Service Location Protocol to find SIP registrar
servers having particular security characteristics. If secure access to
such information is required, SLP security should be used.
Template text:
----------------------template begins here ------------------------
template-type = sip:registrar
template-version = 0.0
template-description=
The service:sip:registrar type provides advertisements for clients
seeking Session Initiation Protocol (SIP) registrar servers.
template-url-syntax = ;inherited from abstract type.
app-services = STRING M L O
#Application services supported by the server. Allowed values are:
#
Kempf, Rosenberg expires August 2000 [Page 10]
INTERNET DRAFT Feburary 2000
# cpl - The server supports Call Processing Language (CPL) upload.
# cgi - The server supports CGI upload.
#
cpl,cgi
non-sip-urls = BOOLEAN O
#True if the server supports nonSIP URLs in Contacts.
----------------------template ends here --------------------------
9. An Example SLP Query
>From the example in Section 8, suppose Joe User's UAC is looking
for a registrar server that supports CPL. The following SLP query
can be used by the UAC to find a registrar server that supports
CPL:
(&(transport=udp)(app-services=cpl))
The transport type is required in all queries (indicated by the 'X'
flag in the template). In this case, the UAC requires UDP.
10. Security Considerations
Service type templates provide information that is used to inter-
pret information obtained by clients through SLP. If the SIP tem-
plate is modified or if a false template is distributed, SIP servers
may not correctly register themselves, and SIP clients may not be
able to interpret service information.
SLP provides an authentication mechanism for SLP UAs to assure that ser-
vice advertisments only come from trusted SAs [2]. If trust is an
issue, particularly with respect to the information sought by the
client about security mechanisms, then SLP authentication should be
enabled in the network.
11. Summary
This document describes how to use SLP to discover a SIP server. SLP
allows the SIP client to specify characteristics of the SIP server
that it requires, such as transport protocol type, SIP services sup-
plied, application services supplied, etc. A service type template
is defined that contains the attributes advertised by SIP servers.
12. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
Kempf, Rosenberg expires August 2000 [Page 11]
INTERNET DRAFT Feburary 2000
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 devel-
oping Internet standards in which case the procedures for copy-
rights 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."
13. References
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg."SIP:
Session Initiation Protocol".RFC 2543, March, 1999.
[2] E. Guttman, C. Perkins, J. Veizades, and M. Day. "Service Loca-
tion Protocol". RFC 2608, July, 1999.
[3] E. Guttman, C. Perkins and J. Kempf. "Service Templates and ser-
vice: Schemes", RFC 2609, July, 1999.
[4] C. Perkins and E. Guttman. "DHCP Options for Service Location
Protocol". RFC 2610, July, 1999.
[5] S. Bradner. "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[6] J. Lennox and H. Schulzrinne. "Call Processing Language Framework
and Requirements". draft-ietf-iptel-cpl-framework-01.txt. A work
in progress.
14. Author's Addresses
James Kempf Jonathan Rosenberg
Sun Microsystems dynamicsoft
Kempf, Rosenberg expires August 2000 [Page 12]
INTERNET DRAFT Feburary 2000
901 San Antonio Rd. 200 Executive Drive
UMPK15-214 Suite 120
Palo Alto, CA, 94040 West Orange, NJ, 07052
USA USA
+1 650 786 5890 +1 732 741 7244
+1 650 786 6445(fax) +1 732 741 4778(fax)
james.kempf@sun.com jdrosen@dynamicsoft.com
Kempf, Rosenberg expires August 2000 [Page 13]