Network Working Group T. Melanchuk Internet-Draft BlankSpace Expires: July 7, 2006 C. Boulton Ubiquity Software Corporation January 3, 2006 Locating Media Resource Control Protocol Version 2 (MRCPv2) Servers draft-melanchuk-speechsc-serverloc-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 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This specification defines and registers a set of Media Feature Tags for the Media Resource Control Protocol Version 2 (MRCPv2). Clients and servers can use these tags in conjunction with the Session Initiation Protocol (SIP) capabilities framework so that client requests can be routed to the server best able to satisfy the clients requirements. Melanchuk & Boulton Expires July 7, 2006 [Page 1] Internet-Draft speechsc-serverloc January 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Registering Capabilities . . . . . . . . . . . . . . . . . 5 4.2. General Request Processing . . . . . . . . . . . . . . . . 6 4.3. Responding to OPTIONS Requests . . . . . . . . . . . . . . 6 5. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 6 6. Indicating Capabilities in Remote Target URIs . . . . . . . . 7 7. Media Feature Tag Definitions . . . . . . . . . . . . . . . . 7 7.1. Speech Recognition . . . . . . . . . . . . . . . . . . . . 7 7.2. Speech Recognition Grammars . . . . . . . . . . . . . . . 8 7.3. DTMF Recognition . . . . . . . . . . . . . . . . . . . . . 9 7.4. Speech Synthesis . . . . . . . . . . . . . . . . . . . . . 9 7.5. Speech Synthesis Type . . . . . . . . . . . . . . . . . . 10 7.6. Speech Synthesis Control Support . . . . . . . . . . . . . 10 7.7. Speech Synthesis Jump Size . . . . . . . . . . . . . . . . 11 7.8. Speaker Verification . . . . . . . . . . . . . . . . . . . 12 7.9. Recorder . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.10. Other Feature Tag Definitions . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. MRCPv2 Media Feature Tag Registration Tree . . . . . . . . 13 9.2. Media Feature Tags . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Melanchuk & Boulton Expires July 7, 2006 [Page 2] Internet-Draft speechsc-serverloc January 2006 1. Introduction The Media Resource Control Protocol Version 2 (MRCPv2) [7] allows client control of network based media processing resources such as speech recognition engines, speech synthesis engines, and speaker verification and speaker identification engines. MRCPv2 protocol messages are sent over a reliable transport connection such as TCP, TLS, or SCTP. Those transport connections, together with media sessions, are established using the Session Initiation Protocol (SIP) [2]. Servers that implement MRCPv2 may only support a subset of the resources defined by the protocol. For example, a server may support a speech recognition engine but not a speech synthesis engine. As well, there are several capabilities of server resources that may vary between servers but are important to a client. For example, a client may need to know that a server has low latency access to specific speech grammars. Clients initiating MRCPv2 sessions may need to have their requests routed to a server that supports the required media processing resources and capabilities. SIP extensions have been defined in RFC 3840 [3] and RFC 3841 [4] that together provide a framework that allows SIP proxies to route requests from a client to an appropriate server based on the server capabilities and the preferences that a client expresses in its request. RFC 3840 defines how a user agent can indicate its capabilities using SIP. RFC 3841 defines how a client can express preferences about server handling of its requests. Each feature or capability has a corresponding IANA registered media feature tag as defined in RFC 2506 [5]. This document describes how MRCPv2 clients and servers can use the capability/preferences framework so that clients can locate a server able to fulfill their request. It also serves as the IANA registration for an MRCPv2 media feature tag tree and registers an initial set of feature tags. 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 implementations. Additional terminology is defined in Section 3 of [3]. Melanchuk & Boulton Expires July 7, 2006 [Page 3] Internet-Draft speechsc-serverloc January 2006 3. Overview This section provides a brief descriptive overview of using the framework defined by RFC 3840 [3] and RFC 3841 [4] in the context of MRCPv2. Readers should refer to [3] and [4] for a complete understanding of the framework and for definitions of the terminology used below. Normative behavior for MRCPv2 servers and clients is provided in the following sections. An MRCPv2 server constructs a feature set, based in part on the MRCPv2 resources and their capabilities that the server supports. This feature set should also describe the set of SIP capabilities as defined in [3] and may contain capabilities defined by other standards. The feature set is indicated by encoding it as parameters of the SIP Contact header in certain requests and responses. It may be indicated to a registrar by including the feature set within a REGISTER request. Registering capabilities allows a proxy to select an MRCPv2 server that supports the resources and capabilities that are requested by a client. Proxies responsible for a domain learn the servers capabilities when they access the location service for that domain. A server may indicate the feature set directly to MRCPv2 clients by including the feature set in response to OPTIONS requests. The feature set may also be included in requests and responses that create dialogs (such as INVITE). MRCPv2 clients can express a preference for a server that supports the resources and capabilities that it requires by constructing a feature set using the same procedures as a server uses to indicate capabilities. These feature preferences are then included in an Accept-Contact header of INVITE requests. Proxies that support the preferences framework, use the preferences expressed by the request, together with the capabilities that servers have indicated through their registrations, to select a request target that most closely reflects the requested preferences. A client may also directly query a server using OPTIONS. An Accept- Contact header is not used in the case of OPTIONS as the response will indicate the capabilities. Proxy routing of requests to an appropriate server depends on proxies and registrars supporting the SIP preferences extension defined in [3]. Even without proxy and registrar support however, MRCPv2 clients and servers can still benefit from using the feature tags defined in this specification by having a client query a server using Melanchuk & Boulton Expires July 7, 2006 [Page 4] Internet-Draft speechsc-serverloc January 2006 OPTIONS. Servers can ensure that a registrar supports the extension by including the "pref" options tag in the Require header of a REGISTER request. Clients can determine that proxies along the path support the extension by including the "pref" options tag in a Proxy-Require header. 4. Server Behaviour MRCPv2 servers MUST follow the procedures defined in Section 5 of [3] to construct a feature set. Feature tags defined in this specification MUST be prefaced with a '+' character and MUST include the prefix "mrcpv2.". Tt is RECOMMENDED that the server provide information on as many feature tags as possible. Any feature tags that meet the criteria defined in [3] MAY be used. 4.1. Registering Capabilities If an MRCPv2 server registers with a registrar, it will generally be registering a contact URI that represents the user agent instance, rather than an address-of-record. In this case, the server SHOULD indicate its capabilities when it registers. A server indicates its capabilities by including the feature parameters, formatted as defined above, as parameters of the Contact header of a REGISTER request. The syntax for feature parameters is provided in Section 9 of [3]. The following is an example REGISTER request from an MRCPv2 server that supports both speech recognition and speaker verification. The Contact header field includes feature tags from [3] that describe the SIP capabilities of the server, and tags from this specification that identify the MRCPv2 resources that the server supports. REGISTER sip:example.com SIP/2.0 From: sip:user@speechresources.example.com;tag=asd98 To: sip:user@example.com Call-ID: hh89as0d-asd88jkk@speechresources.example.com CSeq: 9987 REGISTER Max-Forwards: 70 Via: SIP/2.0/UDP speechresources.example.com;branch=z9hG4bKnashds8 Contact: ;audio;application;automata;mobility="fixed" ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" ;+mrcpv2.speechrecog;+mrcpv2.speakverify" Note that the tags defined in [3] omit the "sip." prefix and do not Melanchuk & Boulton Expires July 7, 2006 [Page 5] Internet-Draft speechsc-serverloc January 2006 include a leading '+' character whereas the tags from this specification with both a leading '+' and the "mrcpv2." prefix. If the server wants to ensure that the registrar supports the preferences framework, it MAY include a Require header field with a value of "pref". A successful response from the registrar means that the registrar will store the feature parameters, and make them available to elements accessing the location service within the domain. In the absence of the Require header field, a registrar that does not understand this extension will simply ignore the Contact header field parameters. A server MUST include its feature parameters when the server refreshes its registration, if it wishes for them to remain active. 4.2. General Request Processing An MRCPv2 server compliant to this specification MUST follow the general UAS behavior defined in section 6 of [4] when it receives a request whose request-URI corresponds to one of its registered contacts. This processing allows the server to honor any preferences expressed by the client in an Accept-Contact or Reject-Contact header field, even if the proxy handling the request does not support the extension. This may result in the server refusing the request if it does not support preferences marked as "Require" by the client. 4.3. Responding to OPTIONS Requests Section 7 of [7] describes how an MRCPv2 client can use an OPTIONS request to discover the resources supported by a server. In this case, the server response could include an SDP-encoded description of the resources supported by the server. Such an SDP-encoded description, which uses the SDP "resource" attribute defined in [7], would overlap with a similar statement encoded as feature parameters of the Contact header. Resource support can be indicated by both SDP "resource" attributes and by the feature tags defined by this specification. When there exists a feature tag that describes a capability that can also be represented with an SDP "resource" attribute, an MRCPv2 server MUST use the "resource" attribute to describe the capability. Resource capabilities, such as available grammars, that do not overlap with "resource" attributes SHOULD be indicated as parameters of the Contact header field of the OPTIONS response. 5. Client Behaviour Melanchuk & Boulton Expires July 7, 2006 [Page 6] Internet-Draft speechsc-serverloc January 2006 An MRCPv2 Client can indicate its preferred server resources and their capabilities using the SIP Accept-Contact header which is defined in [4]. More To Do 6. Indicating Capabilities in Remote Target URIs MRCPv2 clients and servers MAY indicate their capabilities using the Contact header field of target refresh requests and responses. Devices that do so, MUST follow the procedures defined in Section 7 of [3]. Note that target refresh requests that contain SDP are used as part of the offer answer exchange [9]. Any SDP "resource" attributes used here are for the purposes of allocating or deallocating control channels as described in Section 4.2 of [7]. They are not a capability statement and there is no overlap between "resource" attributes and feature tags as described for OPTIONS processing above. 7. Media Feature Tag Definitions This document defines a set of media feature tags for use with MRCPv2. This section serves as the IANA registration for these feature tags, which are made into the MRCPv2 media feature tag tree. New media feature tags are registered in the MRCPv2 tree based on the process defined in Section 9.1. The feature tags in this section are all registered in the MRCPv2 media feature tag tree created by Section 9.1. 7.1. Speech Recognition Media feature tag name: mrcpv2.speechrecog ASN.1 Identifier: New assignment by IANA Summary of the media feature indicated by this tag: This feature tag indicates that the device supports an MRCPv2 compliant speech recognition engine. Values appropriate for use with this feature tag: Boolean. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This Melanchuk & Boulton Expires July 7, 2006 [Page 7] Internet-Draft speechsc-serverloc January 2006 feature tag is most useful in a communications application for describing the capabilities of a device, such as network server offering media processing services. Examples of typical use: Routing a call to a server that can support speech recognition. Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840. 7.2. Speech Recognition Grammars Media feature tag name: mrcpv2.speechrecog.grammars ASN.1 Identifier: New assignment by IANA Summary of the media feature indicated by this tag: Each value of the mrcpv2.speechrecog.grammars (note the plurality) media feature tag indicates the URI of a grammar that the server guarantees to have immediately available if the client forms a session with that server. There should be no perceptible delay to a client to use grammars indicated by this media feature tag. This feature tag is a sub- feature (see Section 2.2 of [5]) of the mrcpv2.speechrecog feature tag defined in Section 7.1. As such, usage of this tag also implies support for a speech recognition engine as defined in Section 7.1 above. Values appropriate for use with this feature tag: String with an equality relationship. Values should be a valid URI. OPEN ISSUE Is octet by octet string comparison sufficient for comparing the URI values of the mrcpv2.speechrecog.grammars media feature tag? The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as network server offering media processing services. Examples of typical use: Routing a call to a server that supports a speech recognition engine that has immediate access to the grammars identified by this media feature tag. Related standards or documents: RFC 3840 Melanchuk & Boulton Expires July 7, 2006 [Page 8] Internet-Draft speechsc-serverloc January 2006 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840. 7.3. DTMF Recognition Media feature tag name: mrcpv2.dtmfrecog ASN.1 Identifier: New assignment by IANA Summary of the media feature indicated by this tag: This feature tag indicates that the device supports an MRCPv2 compliant DTMF recognition engine. Values appropriate for use with this feature tag: Boolean. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as network server offering media processing services. Examples of typical use: Routing a call to a server that can support DTMF recognition. Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840. 7.4. Speech Synthesis Media feature tag name: mrcpv2.speechsynth ASN.1 Identifier: New assignment by IANA Summary of the media feature indicated by this tag: This feature tag indicates that the device supports an MRCPv2 compliant speech synthesis engine of either type defined in Section 3.1 of [7]. Values appropriate for use with this feature tag: Boolean. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as network server offering media processing services. Examples of typical use: Routing a call to a server that can support Melanchuk & Boulton Expires July 7, 2006 [Page 9] Internet-Draft speechsc-serverloc January 2006 speech synthesis. Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840. 7.5. Speech Synthesis Type Media feature tag name: mrcpv2.speechsynth.type ASN.1 Identifier: New assignment by IANA Summary of the media feature indicated by this tag: This feature tag indicates that the device supports an MRCPv2 compliant speech synthesis engine of the type indicated by the value of the feature tag. This feature tag is a sub-feature (see Section 2.2 of [5]) of the mrcpv2.speechsynth feature tag defined in Section 7.4. As such, usage of this tag also implies support for a speech synthesis engine as defined in Section 7.4 above. Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include: basic: The synthesizer is a basic synthesizer according to definition in Section 3.1 of [7]. full: The synthesizer is a full synthesizer according to definition in Section 3.1 of [7]. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as network server offering media processing services. Examples of typical use: Routing a call to a server that can support a specific type of speech synthesis engine. Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840. 7.6. Speech Synthesis Control Support Media feature tag name: mrcpv2.speechsynth.control ASN.1 Identifier: New assignment by IANA Melanchuk & Boulton Expires July 7, 2006 [Page 10] Internet-Draft speechsc-serverloc January 2006 Summary of the media feature indicated by this tag: This feature tag indicates that the device supports the modifications indicated by headers in an MRCPv2 CONTROL request. This feature tag is a sub- feature (see Section 2.2 of [5]) of the mrcpv2.speechsynth feature tag defined in Section 7.4. As such, usage of this tag also implies support for a speech synthesis engine as defined in Section 7.4 above. Values appropriate for use with this feature tag: Boolean The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as network server offering media processing services. Examples of typical use: Routing a call to a server that can support a speech synthesis engine capable of the modifications indicated by headers in an MRCPv2 CONTROL request. Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840. 7.7. Speech Synthesis Jump Size Media feature tag name: mrcpv2.speechsynth.jump-size ASN.1 Identifier: New assignment by IANA Summary of the media feature indicated by this tag: This feature tag indicates the speech length units that are supported be the synthesizer implementation. This feature tag is a sub-feature (see Section 2.2 of [5]) of the mrcpv2.speechsynth feature tag defined in Section Section 7.4. As such, usage of this tag also implies support for a speech synthesis engine as defined in Section Section 7.4 above. Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include: Second: The synthesizer is able to use speech length units expressed in seconds. Melanchuk & Boulton Expires July 7, 2006 [Page 11] Internet-Draft speechsc-serverloc January 2006 Word: The synthesizer is able to use speech length units expressed in words. Sentence: The synthesizer is able to use speech length units expressed in sentences. Paragraph: The synthesizer is able to use speech length units expressed in paragraphs. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as network server offering media processing services. Examples of typical use: Routing a call to a server that can support a speech synthesis engine capable of supporting an MRCPv2 Jump-Size header field value expressed in the indicated speech length units. Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840. 7.8. Speaker Verification Media feature tag name: mrcpv2.speakverify ASN.1 Identifier: New assignment by IANA Summary of the media feature indicated by this tag: This feature tag indicates that the device supports an MRCPv2 compliant speaker verification engine. Values appropriate for use with this feature tag: Boolean. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as network server offering media processing services. Examples of typical use: Routing a call to a server that can support speaker verification. Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840. Melanchuk & Boulton Expires July 7, 2006 [Page 12] Internet-Draft speechsc-serverloc January 2006 7.9. Recorder Media feature tag name: mrcpv2.recorder ASN.1 Identifier: New assignment by IANA Summary of the media feature indicated by this tag: This feature tag indicates that the device supports an MRCPv2 compliant speech recorder. Values appropriate for use with this feature tag: Boolean. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as network server offering media processing services. Examples of typical use: Routing a call to a server that can support a speech recorder. Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840. 7.10. Other Feature Tag Definitions FFS. 8. Security Considerations To Do. 9. IANA Considerations 9.1. MRCPv2 Media Feature Tag Registration Tree This specification serves to create a new media feature tag registration tree, per the guidelines of Section 3.1.4 of RFC 2506 [5] The name of this tree is the "MRCPv2 Media Feature Tag Registration Tree", and its prefix is "mrcpv2.". It is used for the registration of media feature tags that are applicable to the Media Resource Control Protocol Version 2, and whose meaning is only defined within that usage. Melanchuk & Boulton Expires July 7, 2006 [Page 13] Internet-Draft speechsc-serverloc January 2006 The addition of entries into this registry occurs through IETF consensus, as defined in RFC 2434 [6]. This requires the publication of an RFC that contains the registration. The information required in the registration is identical to the IETF tree. As such, specifications adding entries to the registry should use the template provided in Section 3.4 of RFC 2506. Note that all media feature tags registered in the MRCPv2 tree will have names with a prefix of "mrcpv2.". No leading "+" is used in the registrations of the media feature tag tree. 9.2. Media Feature Tags This specification registers a number of new Media feature tags according to the procedures of RFC 2506. These registrations are all made in the newly created MRCPv2 tree for media feature tags. These registrations are: mrcpv2.speechrecog: The information for registering the mrcpv2.speechrecog media feature tag is contained in Section 7.1. mrcpv2.speechrecog.grammars: The information for registering the mrcpv2.speechrecog media feature tag is contained in Section 7.2. mrcpv2.dtmfrecog: The information for registering the mrcpv2.speechrecog media feature tag is contained in Section 7.3. mrcpv2.speechsynth: The information for registering the mrcpv2.speechrecog media feature tag is contained in Section 7.4. mrcpv2.speechsynth.type: The information for registering the mrcpv2.speechrecog media feature tag is contained in Section 7.5. mrcpv2.speechsynth.control: The information for registering the mrcpv2.speechrecog media feature tag is contained in Section 7.6. mrcpv2.speakverify: The information for registering the mrcpv2.speechrecog media feature tag is contained in Section 7.8. mrcpv2.recorder: The information for registering the mrcpv2.speechrecog media feature tag is contained in Section 7.9. 10. Acknowledgments To Do. 11. References 11.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., Melanchuk & Boulton Expires July 7, 2006 [Page 14] Internet-Draft speechsc-serverloc January 2006 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, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [5] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999. [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 11.2. Informative References [7] Burnett, D. and S. Shanmugham, "Media Resource Control Protocol Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-09 (work in progress), December 2005. [8] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999. [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Melanchuk & Boulton Expires July 7, 2006 [Page 15] Internet-Draft speechsc-serverloc January 2006 Authors' Addresses Tim Melanchuk BlankSpace Email: tim.melanchuk@gmail.com Chris Boulton Ubiquity Software Corporation Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@ubiquitysoftware.com Melanchuk & Boulton Expires July 7, 2006 [Page 16] Internet-Draft speechsc-serverloc January 2006 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 (2006). 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. Melanchuk & Boulton Expires July 7, 2006 [Page 17]