SIPPING J. Rosenberg Internet-Draft Cisco Systems Expires: July 23, 2007 January 19, 2007 Identification of Communications Services in the Session Initiation Protocol (SIP) draft-rosenberg-sipping-service-identification-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute 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 reference 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. This Internet-Draft will expire on July 23, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract This document considers the problem of how SIP endpoints can support a multiplicity of distinct SIP services within the context of a single user agent. The principle problem to be addressed is that of dispatching of incoming requests to the right services, and how service contexts are matched up between calling and called parties. This document proposes the usage of service URN and service URI to solve the problem. Rosenberg Expires July 23, 2007 [Page 1]
Internet-Draft Service ID January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Concepts and Terminology . . . . . . . . . . . . . . . . . . . 4 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 7. UA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Publication . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Session Initiation . . . . . . . . . . . . . . . . . . . . 10 7.4. Receipt of a Request . . . . . . . . . . . . . . . . . . . 11 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Request Targeting . . . . . . . . . . . . . . . . . . . . 12 8.2. Application Invocation . . . . . . . . . . . . . . . . . . 12 9. Guidelines for Using Service URN . . . . . . . . . . . . . . . 13 10. Guidelines on Namespace Structure . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 15.1. Normative References . . . . . . . . . . . . . . . . . . . 17 15.2. Informational References . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Rosenberg Expires July 23, 2007 [Page 2]
Internet-Draft Service ID January 2007 1. Introduction The Session Initiation Protocol (SIP) [2] defines mechanisms for initiating and managing communications sessions between agents. These agents can be entities such as hardphones, softphones, or gateways to other networks, such as the PSTN. These agents are addressed by SIP URI, and in particular, a SIP Address-of-Record or AOR. However, in practice, the entities participating in a call can be more complicated. An agent might be inside of a cell phone, supporting traditional telephony, Push-To-Talk, and voice and data content as part of an interactive game. Furthermore, the servers within the network itself might provide additional functions, such as call screening or call recording. These functions are often referred to as 'services', 'features' or 'applications'. Their usage raises questions on how users invoke them, how they are identified, and how interoperability between them is provided. Section 3 defines the problem in more detail. Section 4 defines concepts and terminology. Section 5 introduces requirements for the solution. Section 6 overviews the solution, and Section 7 defines detailed procedures for user agents, while Section 8 defines procedures for proxies. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant STUN implementations. 3. Problem Statement Consider a device that allows the user to select two applications. One of these applications is a traditional telephony application, which lets the user make and receive phone calls using telephone numbers. The second application is a two-player chess game that utilizes voice commands to move pieces. When one player says "Queen to D7", the software on their phone recognizes this and moves the piece. At the same time, the user's voice is sent to the other player, where it is both rendered to the user, and interpreted locally in order to move the piece. If the user should make a call using the telephony application, the Rosenberg Expires July 23, 2007 [Page 3]
Internet-Draft Service ID January 2007 result would be a SIP INVITE for a single voice media stream. Interestingly, if the user launches the game application, the same is true - the result would be a SIP INVITE for a single voice media stream. However, depending on which application the caller selected, the appropriate application at the called party must also be selected. It would be nonsensical for the user to invoke the telephony application and be connected to the gaming application on another user's device. The user interface for the gaming application would not function properly, and the overall experience would be poor. What is needed is some kind of way to differentiate these two applications. A similar problem arises in the invocation of outbound applications that reside in the network. Consider once more our user with the telephony and gaming application. The user wishes to make a telephony call, but wants the call to be recorded. The recording option is available on a call-by-call basis. The recording application itself resides on a server in the domain of the caller, and acts as a back-to-back user agent (B2BUA) in order to perform the call recording (there are alternative models involving the application interaction framework [9] and conferencing [12], but the specific mechanism is not relevant to the discussion here). When the user initiates the call, how do they signal to their outbound proxy that the call needs to pass through the recording application? In both cases, the problem at hand is the identification and invocation of applications which reside either on the endpoint (in the first example) or in the network (in the second example). 4. Concepts and Terminology The problem of identifying and invoking services within SIP is not a new one. The problem has been considered extensively in the context of presence. In particular, the presence data model for SIP [14] defines the concept of a service as one of the core notions that presence describes. Services are described in Section 3.3 of RFC 4479, which has this to say on the topic: 3.3. Service Each presentity has access to a number of services. Each of these represents a point of reachability for communications that can be used to interact with the user. Examples of services are telephony (that is, traditional circuit-based telephone service), push-to-talk, instant messaging, Short Message Service (SMS), and Multimedia Message Service (MMS). Rosenberg Expires July 23, 2007 [Page 4]
Internet-Draft Service ID January 2007 It is difficult to give a precise definition for service. One reasonable approach is to model each software or hardware agent in the system as a service. If a user starts a softphone application on their PC, then that represents a service. If a user has a videophone device, then that represents another service. This is effectively a physical view of services. This definition, however, starts to fall apart when a service is spread across multiple software agents or devices. For example, a SIP URI representing an address-of-record can be routed to a softphone or a videophone, or both. In that case, one might attempt instead to define a service based on its address on the network. This definition also falls apart when modeling devices or applications that receive calls and dispatch them to different "helpers" based on potentially complex logic. For example, a cellular telephone might house multiple SIP applications, each of which can "register" different handlers based on the method or even body type of the request. Each of those applications or handlers can rightfully be considered a service, but it doesn't have an address on the network distinct from the others. Because of this inherent difficulty in precisely defining a service, the data model doesn't try to constrain what can be considered a service. Rather, anything can be considered a service so long as it exhibits a set of key properties defined by this model. In particular, each service is associated with characteristics that identify the nature and capabilities of that service, with reach information that indicates how to connect to the service, with status information representing the state of that service, and relative information that describes the ways in which that service relates to others associated with the presentity. As a consequence, in this model, services are not explicitly enumerated. There is no central registry where one finds identifiers for each service. Consequently, each service does not have a single "service" attribute with values such as "ptt" or "telephony". That doesn't mean that these consolidated monikers aren't useful; indeed, they represent an essential summary of what the service is. Such summarization is useful in creating icons that allow a user to choose one service over another. A watcher is free to create such summarization information from any of the information associated with a service. The reach information often provides valuable information for creating such a summarization. Oftentimes, the scheme of the URI is synonymous with the view of what a service is. An "sms" URI [14] clearly indicates SMS, for example. For some URIs, there may be many services available, for example, SIP or tel [15], in which case the scheme is less meaningful as a way of creating a summary. The reach information could also indicate that certain application software has to be invoked (such as a videogame), in which case that aspect of the reach information would be useful for generating an iconic Rosenberg Expires July 23, 2007 [Page 5]
Internet-Draft Service ID January 2007 representation of the game. Building upon this, we can model a user agent as containing a SIP processing layer ontop of which sit a number of different SIP services, as shown in Figure 2 +---------------------------------+ | | | +-------------+ +-------------+ | | | UI | | UI | | | +-------------+ +-------------+ | | +-------------+ +-------------+ | | | | | | | | | Service 1 | | Service 2 | | | | | | | | | +-------------+ +-------------+ | | +-----------------------------+ | | | | | | | SIP | | | | Layer | | | | | | | +-----------------------------+ | | | +---------------------------------+ Physical Device Figure 2 The role of the SIP layer is to parse incoming messages, handle the SIP state machinery for transactions and dialogs, and then dispatch request to the appropriate service. The dispatching operation is based on any number of criteria in the SIP message itself. For example, the method might be used to dispatch the request. A messaging application on the phone would be dispatched when a MESSAGE request arrives. Similarly, when a user interacts with the device, they would select a specific service, and then use that service to initiate communications. The service would then request the SIP layer to send an appropriate message, depending on what was needed. Each service has a user interface (UI) that dictates how it interacts with the user. SIP uses URI, and in particular, SIP URI, to identify resources within the system. The Address-of-Record, or AOR, identifies the user that is the originator or target of the request. The Globally Routable User Agent URI (GRUU) [4] identifies a specific instance of a user agent. In the model of Figure 2, there is still but one user Rosenberg Expires July 23, 2007 [Page 6]
Internet-Draft Service ID January 2007 agent, and thus a single GRUU. However, we have effectively introduced a layer of hierarchy into the system. Within a particular UA instance, there can be one or more service instances. Each service instance can be addressed by a URI. This URI is formed by adding a parameter, at the discretion of the UA, to the GRUU. The resulting URI is called a service instance URI. When a service spans multiple devices and multiple SIP UA instances, the aggregate set is represented by a service URI. Typically, a domain will need to construct such a URI, and bind it to the various service instances that can be reached through the service URI. In addition, each service may or may not be a well-known service. A well-known service is identified by a service URN [5]. The URN refers to the set of assumptions and processing requirements within the service layer that define how a request is processed. For example, a service URN of urn:service:games:voice-chess could be used to identify the voice chess application described in Section 3. In this case, the URN would need to be standardized, and there would be agreement that the "context" is that voice is interpreted by speech recognition for the purposes of performing chess moves, and a specific set of phrases would be agreed upon. It is also possible to have vendor specific services, which would be identified using a URN such as "urn:service:vnd:example.com:foobar", which refers to the foobar service produced by a specific vendor. It is extremely important to note that this name refers to the additional logic that is required in the processing of a SIP session in order for it to be successfully utilized. SIP assumes that the "normal" service is multimedia communications - the exchange of real time media between the users which generated and received the requests for the purpose of communications between humans or automata which act like a human. The chess example is more than this, because the media is additionally consumed by an automata that is looking to do specialized processing, and because the media is not primarily for human communication, its for controlling moves on a chess board. Because of this, a traditional communications applications has no well-known service associated with it. 5. Requirements REQ 1: It shall be possible for an incoming request to be dispatched to the correct service on a device. Rosenberg Expires July 23, 2007 [Page 7]
Internet-Draft Service ID January 2007 REQ 2: When multiple services reside on a single device, sharing a single SIP layer, it must not require multiple registrations. This is primarily a performance and overhead requirement. REQ 3: It shall be possible to support cases where sessions initiated from a particular service purposefully fail unless they can be connected to a matching service for the called party. REQ 4: It must be possible for services to "match" based on proprietary and well-known identifiers. REQ 5: It must be possible for a user to initiate a session without knowledge of any information about the recipient except for their AOR. REQ 6: The mechanism must allow a presence server to determine the services on the phone, without requiring advanced knowledge of those services. REQ 7: It must be possible to support cases where sessions initiated from a service on the caller side connect to a different service on the other side in cases where the session is meaningful when the notions of service on each side do not match. 6. Overview of Operation The proposed solution to the problem is relatively straightforward. The essential problem is that there are cases where a session cannot take place correctly unless the terminating party implements a certain piece of service logic. This is directly analagous to the case where a session cannot take place correctly unless the terminating party implements a certain SIP extension correctly; the problem is just occurring at a different layer in the stack based on the model of Figure 2. Consequently, the proposed solution is similar. The Require header field is utilized, and the option tag is just the service URN for the well-known service, suitably escaped. When a request with a Require header arrives at the home proxy of the UAS, the home proxy utilizes implicit preferences, as described in RFC 3841 [3]. This will prefer routing of the request to contacts which have indicated support for those extensions. The UAS itself uses the Require header field to dispatch the request to the correct service instance. In addition, the user agents make use of UA loose routing [6] and GRUU [4], and add an implementation-specific parameter to their GRUU Rosenberg Expires July 23, 2007 [Page 8]
Internet-Draft Service ID January 2007 for each service instance on a device. This allows future out-of- dialog and mid-dialog requests to be targeted at the right service instance, and provides a simple mechanism for dispatch in the device, based entirely on the URI. When a UAC wants the request to be processed by an application prior to reaching the terminating proxy, it includes the service URN in Route headers that get appended to the route set for the request. For example, if a UA wants a call to be recorded, it would include a service URN like "urn:service:comm:recording" to the bottom-most Route header. This will cause an originating proxy to resolve the service URN to a URI for an application server, and then proxy the request there. In order to discover available services on a device, presence can be used. A UA would just SUBSCRIBE to the presence of the AOR, and get back a document that contains a service element for each service available for that user. The presence document includes the service URN for any well-known services (noting again that this is only needed when other information, such as method or media types, are insufficient to define the service). The service URN can then be used for creating summary information about the service. The URI present in the contact for that service is the service instance URI or service URI. The former is published by the UA to the network in a presence document, and the latter may be constructed by the network when composing documents together. 7. UA Behavior 7.1. Registration When a UA supports numerous services, it SHOULD generate a single registration representing the entire UA instance. The UA MUST utilize GRUU [4] and UA loose routing [6]. If any of the services on the UA are well-known services, the UA SHOULD include their URNs as option tags in the extensions media feature tag in the Contact header field parameter. The media feature tags can help the network construct presence documents when the UA doesn't publish them separately (though this is recommended as described below). They are also used for routing of requests. NOTE: An alternative design would be to have each service instance be a separate registered Contact. This would be more helpful for presence, though not needed if a PUBLISH is used. However it has the drawback of adding more state to the network and exposing Rosenberg Expires July 23, 2007 [Page 9]
Internet-Draft Service ID January 2007 "internal" routing within the UA to outside of the UA. It would mean that the proxy would need to know the dispatch logic, which is more likely to be known by the UA. 7.2. Publication If the UA supports presence, it SHOULD PUBLISH [7] a presence document for itself. This document SHOULD include a service (represented by a tuple) for each service instance. The contact of each tuple SHOULD be derived from the GRUU, and constructed by adding a UA-defined parameter to the GRUU for each service instance. The parameter MUST be different for each service instance, and SHOULD persist over time. The UA SHOULD include information that identifies what the service is, including supported methods and media types, when those are important for its definition. For services that require well-known logic, the agent SHOULD include the service URN amongst the extensions listed for that service. The UA can do a better job constructing the presence document than the registrar. This is because the UA knows what mechanisms are used to dispatch requests to each service, and knows what well- known service URN are associated with each service. Having an explicit contact for each service allows a UA to unambiguously be reached based on a service selection made by a watcher. This is important, since choice is a key concept provided by presence [14]. 7.3. Session Initiation A UA can initiate a session either directly, or using presence. When using presence, the UA would start with the AOR for the target. It subscribes to the presence state for the AOR [8]. The result will be a presence document that includes a tuple for each service. The services will include information that describe them with sufficient information for the user to choose one. This may include well-known service URN associated with each service. When the user selects a service for the target user, the UA will generate an INVITE to the contact listed there. Since this contact is a service instance URI or service URI, the request will be routed towards the target UA and explicitly identify the desired service by the URI alone. Of course, when the UA selected the service to contact, the request would have been initiated from a matching service on the device. In that case, if the initiating request is associated with a required well-known service, the corresponding escaped service URN MUST appear as an option tag in the Require header field. Rosenberg Expires July 23, 2007 [Page 10]
Internet-Draft Service ID January 2007 When initiating a session directly, the user will select a service on the phone and then request communications by entering or selecting the target AOR. If the service from which the request is being made is associated with a required well-known service, the corresponding escaped service URN MUST appear as an option tag in the Require header field. This has an important procedural side effect. Based on the rules of the SIP change processs [15], the Require header field can only contain option tags defined in standards track documents. Otherwise, the resulting protocol cannot be considered SIP. This also means that a UA can only require well-known services when they are IETF defined. Otherwise, the resulting protocol is proprietary. This was purposefully done to help temper usage of the mechanism, which can cause significant interop problems if abused. RFC 3261 uses the 'token' construct for option tags. The service URN is a valid token with the exception of the colon (:). Consequently, when used as an option tag, a service URN MUST be escape coded by replacing the colon with an exclamation point (!). When initiating a session from a presence document, there is no need for the UA to insert any Require header fields or otherwise add any content to the request beyond what is implied by the contact URI. This does not prevent a UA from inserting one when the UA does in fact require that a specific well-known service be present. The Contact header field of a dialog forming request SHOULD be formed by taking the GRUU, and adding a URI parameter (at the discretion of the UA) which identifies the particular service invoking the request. The resulting URI is called the service instance URI. If a UA wants the network to pass the request through application servers that provide specific processing, the UA MUST include a service URN for that service as the bottom-most Route header. The service URN that are available to the UA are learned through mechanisms outside the scope of this specification, and can include configuration [10] for example. If the UA wants the request to be processed by multiple applications, it MUST include a Route header value for each service URN. The UA SHOULD order them based on desired order of invocation, if known. 7.4. Receipt of a Request When a UA receives a request, it MAY use any content of the request in order to determine which service on the device is appropriate for handling the request. This includes the method, media types, and Rosenberg Expires July 23, 2007 [Page 11]
Internet-Draft Service ID January 2007 required extensions, including any service URN that might be present in the Require header field. The specific means by which a service "registers" itself with the underlying SIP layer to drive the dispatch logic is a matter of local implementation and outside the scope of this specification. Of course, if the UAS doesn't understand one of the option tags in the Require header field, it will generate a 420 response and include the list of unsupported option tags, including those which happen to be service URN. This is helpful for diagnosing interoperability problems due to incompatible services. Once the request is delivered to the service instance for processing, any response SHOULD include the service URI derived from the GRUU in the Contact header field. 8. Proxy Behavior 8.1. Request Targeting When a home proxy receives a request and uses the location service to route the request, it SHOULD follow the procedures defined in RFC 3841 [3] for preference and capability matching. These SHOULD be done even if the request did not contain an Accept-Contact or Reject- Contact header field. When neither was present, the proxy will construct implicit preferences based on the rules in Section 7.2.2 of RFC 3841. In addition, a proxy SHOULD construct an explicit preference for extensions when the request contains a Require header field. For each option tag in the Require header field, the proxy adds a term to the conjunction of the following form: (sip.extension=[option tag]) This would include any option tags that were service URN. The result will be that calls get routed to devices which understand the required service. 8.2. Application Invocation When a proxy receives a request where the next Route header field value after the proxy itself contains a service URN, the proxy MUST resolve the service URN to a SIP URI that can be used to perform that service. The specific mechanism for resolution is outside of the scope of this specification. It can include standardized resolution services such as DDDS [16] or LoST [11], or can be done through local Rosenberg Expires July 23, 2007 [Page 12]
Internet-Draft Service ID January 2007 configuration. If there are more than one consecutive Route header field values with service URN, a proxy MAY resolve all of them, and MAY reorder them based on localized knowledge of the required invocation sequence. This is particularly important when the proxy is aware of additional applications that need to be invoked, for which it needs to add additional Route header field values. 9. Guidelines for Using Service URN This document introduces the concept of using a service URN to identify well-known logic that is required in order to successfully process a request. Care must be taken in the usage of this mechanism, or serious interoperability problems can occur. For example, consider an extreme example whereby the vendor of a UA defines a service URN for each version of their software, under the assumption that the logic in the UA represents a well-known service. If multiple vendors do this, a request from one vendor's device will fail to interoperate with the devices from any other vendor, even if they would be interoperable otherwise. Consider a more realistic case where a service provider chooses to utilize a well-known service URN for voice telephony and another one for video telephony. There is nothing unique about the actual service logic used to realize each. However, calls made from the video telephony application include a Require header field, requiring the usage of video telephony on the other side. If the call should reach a device that supports only voice, such as a PSTN gateway, the call will automatically fail. However, had existing SIP negotiation techniques been utilized (in this case, the ability to reject media streams), the call would have succeeded. It is for this reason that the well-known service URN in the Require header field are restricted in several ways. Firstly, they are meant specifically and exclusively for usage in cases where some service logic must be present and matching on both the originating and terminating sides in order for any type of reasonable communications to exist. Secondly, it is limited to capabilities that cannot be negotiated or indicated by other SIP techniques (such as support for a specific media type). One metric for this is that, absent the option tag in the Require header, a request to initiate the session would be identical to a request to or from a different service that is not actually interoperable. Furthermore, the SIP change process forbids the usage of vendor Rosenberg Expires July 23, 2007 [Page 13]
Internet-Draft Service ID January 2007 proprietary option tags in the Require header field. This means that IETF standardization is required for the definition of service URN that would be used with the mechanism proposed here. 10. Guidelines on Namespace Structure The service URN [5] creates a basic namespace in which services can be registered. When a new service is added, care should be taken to make sure it is as general purpose as possible while still preserving interoperability. When variations are possible, but for which interoperability exists, these SHOULD be registered using subservices. This specification requests IANA to create the "vendor" top-level service for vendor specific services. Each sub service MUST be constructed by taking the domain name of the vendor (example.com for example), and following that by a vendor-defined subservice that identifies their service. For example, if vendor example.org wants to create a service called foo, its service URN would be "urn:service:vendor.example.org.foo". Note that these subservices are not IANA registered, and that vendor-defined service URN are not IANA registered SIP option tags. 11. Security Considerations This specification makes use of option tags and URI to facilitate routing of a request to the appropriate service instance. An attacker in the network could modify these fields to cause the request to be routed to the wrong service instance, which would worsen user experience and possibly cause an interoperability failure. Such an attack would require a man-in-the-middle to modify SIP requests. An attacker capable of such modifications can launch far more disruptive attacks by manipulating other fields, such as Contact or the SDP. Consequently, such attacks do not seem likely. 12. IANA Considerations This specification registers a new service URN label per the guidelines in Section 4 of [5]. This represents vendor-proprietary services. Allocation of subservices is done using hierarchical allocation [13] and requires no IANA action. Here is the information to be added to the table of service URN: Rosenberg Expires July 23, 2007 [Page 14]
Internet-Draft Service ID January 2007 Service: vendor Specification: RFC XXXX [[NOTE TO RFC-EDITOR: Please replace XXXX with the RFC number of this specification.]] Brief Description: Vendor proprietary service tree 13. Example Consider our example from Section 3. A user, joe@example.com, starts their chess application and wishes to play with bob@example.com. Joe's INVITE would look like: INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a From: Joe <sip:joe@example.com>;tag=n88ah To: Bob <sip:bob@example.com> Call-ID: 1j9FpLxk3uxtma7@host.example.com CSeq: 1 INVITE Supported: gruu Require: urn!service!chess <allOneLine> Contact: <sip:joe@example.com ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> ;service=chess </allOneLine> Content-Length: -- Content-Type: application/sdp [SDP Not shown] Note that the request contains a Require header field with the service URN. The Contact header field contains a GRUU, and Joe's UA has added a parameter, "service=chess" to this URI. This parameter is used only by Joe's UA for dispatching the request to the chess application when a request is sent to that URI. In another example, a Joe receives a presence document indicating that the chess service is supported for Bob: Rosenberg Expires July 23, 2007 [Page 15]
Internet-Draft Service ID January 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid" xmlns:caps="urn:ietf:params:xml:ns:pidf:caps" xmlns:su="urn:ietf:params:xml:ns:pidf:urn-caps" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entity="sip:bob@example.com"> <tuple id="sg89ae"> <status> <basic>open</basic> </status> <dm:deviceID>mac:8asd7d7d70</dm:deviceID> <caps:servcaps> <caps:extensions> <caps:supported> <su:urn>urn:service:chess</su:urn> </caps:supported> </caps:extensions> </caps:servcaps> <contact>sip:bob@example.com ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf7> ;service=chess</contact> </tuple> <dm:person id="p1"> <rp:activities> <rp:on-the-phone/> </rp:activities> </dm:person> <dm:device id="pc122"> <rp:user-input>idle</rp:user-input> <dm:deviceID>mac:8asd7d7d70</dm:deviceID> </dm:device> </presence> Joe's UA notices that the chess service is available by the service URN, and it renders an icon representing that service. When Joe selects it, the chess application launches and generates an INVITE. Note that the chess application itself will include a Require header field, since chess has to be supported on the far end to proceed with the call: Rosenberg Expires July 23, 2007 [Page 16]
Internet-Draft Service ID January 2007 <alloneline> INVITE sip:bob@example.com ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf7> ;service=chess SIP/2.0 </alloneline> Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a From: Joe <sip:joe@example.com>;tag=n88ah To: Bob <sip:bob@example.com> Call-ID: 1j9FpLxk3uxtma7@host.example.com CSeq: 1 INVITE Supported: gruu Require: urn!service!chess <allOneLine> Contact: <sip:joe@example.com ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> ;service=chess </allOneLine> Content-Length: -- Content-Type: application/sdp [SDP Not shown] 14. Acknowledgements This document is based on discussions with Paul Kyzivat and Andrew Allen, who contributed significantly to the ideas here. 15. References 15.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [4] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-11 (work in progress), October 2006. Rosenberg Expires July 23, 2007 [Page 17]
Internet-Draft Service ID January 2007 [5] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-05 (work in progress), August 2006. [6] Rosenberg, J., "Applying Loose Routing to Session Initiation Protocol (SIP) User Agents (UA)", draft-rosenberg-sip-ua-loose-route-00 (work in progress), October 2006. [7] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. 15.2. Informational References [9] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", draft-ietf-sipping-app-interaction-framework-05 (work in progress), July 2005. [10] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-09 (work in progress), October 2006. [11] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-ietf-ecrit-lost-02 (work in progress), October 2006. [12] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [14] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [15] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. [16] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. Rosenberg Expires July 23, 2007 [Page 18]
Internet-Draft Service ID January 2007 Author's Address Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 Email: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Expires July 23, 2007 [Page 19]
Internet-Draft Service ID January 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires July 23, 2007 [Page 20]