Internet DRAFT - draft-melanchuk-speechsc-serverloc
draft-melanchuk-speechsc-serverloc
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: <sip:user@speechresources.example.com>
;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]
