Before Internet telephony can become a widely deployed service, a number of protocols must be deployed. These include signaling and capabilities exchange, but also include a number of "peripheral" protocols for providing related services. The primary purpose of this working group is to develop three such supportive protocols. They are: 1. User Location. When placing a telephone call to a user, it is necessary for a client (or a proxy for that client) to determine the location of the user, so that they can be contacted. This location is generally of the form of a telephone number or IP address. The caller starts with either an email style address or a telephone number. These must be mapped into the location where it is appropriate for the caller to actually contact the callee. Unlike traditional mappings, such as DNS, which are fairly static and flat, this mapping depends on a variety of factors. It can be based on caller preferences (I want j.doe@company.com at home), callee preferences (connect the caller to my voicemail if its Bob), and status (connect the caller to my PC if I'm logged in, cell phone otherwise). Telephone numbers must also be mapped - 800-555-1212 might be mapped to the IP address of some directory service, for example. Such a mapping should also support personal mobility, so that names like j.doe@ieee.org can be mapped to wherever that individual is currently residing. Such a location service requires a protocol which can forward user location requests from server to server. At each server, some local database is accessed (the type and scope of such accesses our outside the scope of the working group, and can include anything from finger to LDAP to TCAP) to determine the next server to forward the request to. The Session Initiation Protocol (SIP - draft-ietf-mmusic-sip under development in mmusic) provides much of this functionality already. The IPTEL working group will define a profile for SIP that adds a few additional pieces of functionality required for this service. In particular, SIP handles only email-like identifiers at the moment. Support for telephone numbers must be added. Additional parameters will also be required to provide richer user location services. Finally, SIP currently mixes call control and user location. The IPTEL working group must separate these two, allowing use of the location service without call control, which may be handled by other protocols such as H.323. Of course, the IPTEL working group is not hard set on SIP, and would entertain other proposals for performing user location. The output of this work will be a single standards track RFC, likely defined as an extension to SIP. 2. Call Processing Syntax. As part of the location service just described, a callee can express preferences about where they would like to be contacted - home PC, office PC, office telephone, beeper, etc. In order to allow servers, such as H.323 gatekeepers, to act on callee preferences, some kind of preference syntax must be developed. This syntax would be transmitted by the client to the server, allowing the server to process calls based on client preferences. The group will develop this syntax, and specify means of securely transporting and extending it. The result will be a single standards track RFC. 3. Gateway Attribute Distribution Protocol. When making a call between an IP host and a PSTN user, a telephony gateway must be used. The selection of such gateways is based on client expressed preferences, and availability of gateways. Since gateways outside of the hosts' autonomous system might be used, a protocol is required to allow gateways to distribute their attributes (such as PSTN connectivity, supported codecs, etc.) to entities which must route to the PSTN. The group will investigate and design a protocol for this purpose, generate an Internet Draft, and advance it to RFC if appropriate.