Subject: Discovering SIP Servers

From: James Kempf <[email-masked]>
Date: Tue, 15 Feb 2000 11:21:59 -0800 (PST)

Attached is an individual submission on how to find SIP servers using
SLP, including a service template for SIP. The service template defines
the SLP attributes advertised by a SIP server for discovery. The
draft may be of interest to members of the group, which is why 
I've posted it.

As an aside, there has been some concern expressed on other lists about
the size of an SLP implementation, which might impact the usability
of SLP in small devices, such as phones. We have done a client side 
implementation of the minimal SLP UA specified by RFC 2608 in 5K of uncompressed 
Java bytecodes.

Please send any comments, questions, and criticisms

		jak

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:

                        |
                        | [email-masked]
                        |
                        |
                        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:

                        |
                        | [email-masked]
                        |
                        |
                        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 <[email-masked]>
                    Jonathan Rosenberg <[email-masked]>
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 <[email-masked]>
                    Jonathan Rosenberg <[email-masked]>
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 <[email-masked]>
                    Jonathan Rosenberg <[email-masked]>
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)
[email-masked]                             [email-masked]

Kempf, Rosenberg          expires August 2000                  [Page 13]

---

From: Francois Menard List Account <[email-masked]>
Date: Tue, 15 Feb 2000 15:16:49 -0500 (EST)

Excellent!

I welcome this initiative.

Will Sun release the source code of the minimal UA implementation ?

-=Francois=-