# 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. # 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. # Introduction # 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. The sip.1.0.en template 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. # 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]. # 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 # # 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. # # 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 sip.1.0.en template. # # 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 # # 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. # 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. # 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 # 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 | +----------------+ # +--------------+ # # 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 # top level proxy to have a list of all possible proxies the user # may have registered at. It could discover these using SLP (see # "SIP Servers as SLP UAs" 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. # # 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. # 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. # 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. # 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. # Author's Addresses # James Kempf Jonathan Rosenberg # Sun Microsystems dynamicsoft # 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 # Full Copyright Statement # Copyright (C) The Internet Society (1997). 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 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." # SIP Abstract Service Type template-type = sip template-version = 1.0 template-description= The abstract service:sip type provides advertisements for clients seeking 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 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.