Network Working Group L. Miniero
Internet-Draft A. Amirante
Expires: August 15, 2008 T. Castaldi
S P. Romano
University of Napoli
February 12, 2008
A Binary Floor Control Protocol (BFCP) Control Package for the Session
Initiation Protocol (SIP)
draft-miniero-bfcp-control-package-00.txt
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 August 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines a Session Initiation Protocol (SIP) Control
Package for BFCP-based conference moderation. The control of Media
Servers and their related resources in decomposed network
architectures plays an important role in various Next Generation
Networks. This Control Package aims at adding BFCP functionality to
Miniero, et al. Expires August 15, 2008 [Page 1]
Internet-Draft BFCP Control Package February 2008
conferences using the SIP Control Framework.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Control Package Definition . . . . . . . . . . . . . . . . . . 4
5.1. Control Package Name . . . . . . . . . . . . . . . . . . . 4
5.2. Framework Message Usage . . . . . . . . . . . . . . . . . 4
5.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 5
5.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 5
5.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 5
6. Element Definitions . . . . . . . . . . . . . . . . . . . . . 6
6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1.1. <moderateconference> . . . . . . . . . . . . . . . . . 6
6.1.2. <unmoderateconference> . . . . . . . . . . . . . . . . 7
6.1.3. <addfloor> . . . . . . . . . . . . . . . . . . . . . . 8
6.1.4. <modifyfloor> . . . . . . . . . . . . . . . . . . . . 8
6.1.5. <removefloor> . . . . . . . . . . . . . . . . . . . . 9
6.1.6. <addparticipant> . . . . . . . . . . . . . . . . . . . 10
6.1.7. <removeparticipant> . . . . . . . . . . . . . . . . . 10
6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. <response> . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 11
6.3.1. <subscribe> . . . . . . . . . . . . . . . . . . . . . 11
6.3.2. <event> . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Floors Manipulation . . . . . . . . . . . . . . . . . . . 12
6.4.1. <floor> . . . . . . . . . . . . . . . . . . . . . . . 13
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Miniero, et al. Expires August 15, 2008 [Page 2]
Internet-Draft BFCP Control Package February 2008
1. Introduction
The SIP Control Framework [11] provides a generic approach for
establishment and reporting capabilities of remotely initiated
commands. The Framework utilizes many functions provided by the
Session Initiation Protocol (SIP) [4] for the rendezvous and
establishment of a reliable channel for control interactions. The
Control Framework also introduces the concept of a Control Package.
A Control Package is an explicit usage of the Control Framework for a
particular interaction set. This specification defines a package for
floor control in conferences based on the use of the Binary Floor
Control Protocol (BFCP) [8].
2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [2] and indicate requirement levels for
compliant implementations.
3. Terminology
TBD.
4. Overview
The SIP Control Framework [11] provides a generic approach for
establishment and reporting capabilities of remotely initiated
commands. The Framework utilizes many functions provided by the
Session Initiation Protocol (SIP) [4] for the rendezvous and
establishment of a reliable channel for control interactions. The
Control Framework also introduces the concept of a Control Package.
A Control Package is an explicit usage of the Control Framework for a
particular interaction set. This specification defines a package for
floor control in conferences based on the use of the Binary Floor
Control Protocol (BFCP) [8].
Floor control is needed whenever access to a resource, or set of
resources, needs to be moderated. A typical example is the right to
talk in a conference. In such a scenario, a participant willing to
talk would first have to place a request concerning the floor
associated with such audio resource. The participant would then be
added to the conference mix only when his request has been granted,
by the server itself or by a designated chair. RFC4582 [8] defines a
Miniero, et al. Expires August 15, 2008 [Page 3]
Internet-Draft BFCP Control Package February 2008
Binary Floor Control Protocol (BFCP) to specifically deal with such a
need. It defines all the relevant entities (floors, queues,
requests) and related actors (floor control servers, participants and
chairs). So, the scope of this package is adding BFCP-based floor
control functionality to complementary packages that might need it,
as the Conference Control Package [13].
In particular, this package aims at dealing with the case where the
Floor Control Server (FCS), as defined in [8], is co-located with the
Media Server (MS). In fact, if the FCS were co-located with the
Application Server (AS), floor control would be part of the AS
application logic, and consequently out of scope for the MS.
Considering users are added by the AS to the MS by means of a 3PCC
[6] mechanism, a way to include BFCP negotiation is needed. In fact,
users willing to act as floor participants will need to be made aware
of all the relevant identifiers (i.e. the transport address of the
floor control server, the BFCP conference ID associated with the mix,
the BFCP user ID the user has been assigned, all the floor
identifiers and their mapping with existing resources, and so on) to
opportunely interact with a floor control server. To achieve this,
RFC4583 [8] provides with a way to negotiate BFCP connections within
the context of a SDP offer/answer [5].
5. Control Package Definition
This section fulfills the mandatory requirement for information that
MUST be specified during the definition of a Control Framework
Package, as detailed in Section 9 of [11].
5.1. Control Package Name
The Control Framework requires a Control Package definition to
specify and register a unique name and version.
The name and version of this Control Package is "msc-conf-bfcp/1.0"
(Media Server Control - Conferencing - BFCP - version 1.0 ).
5.2. Framework Message Usage
BFCP functionality includes several different capabilities. There
must be means to appropriately create, modify and destroy each of the
available resources. This includes means to create a BFCP conference
with specified settings, adding and removing floors to the
conference, setting or unsetting designated chairs for such floors
and so on.
This package defines XML elements in Section 6 and provides an XML
Miniero, et al. Expires August 15, 2008 [Page 4]
Internet-Draft BFCP Control Package February 2008
Schema in Section 8. Additionally, some examples are provided in
Section 7.
The XML elements in this package are split into requests, responses
and event notifications. Requests are carried in CONTROL message
bodies; <moderateconference> and <addfloor> elements are examples of
package requests. Responses are carried either in REPORT message or
Control Framework 200 response bodies; the <response> element is
defined as a package response. Event notifications are also carried
in REPORT message bodies; the <event> element is defined for package
event notifications. Event subscription is accomplished by means of
the <subscribe> element.
Note that package responses are different from framework response
codes. Framework error response codes (see Section 8 of [11]) are
used when the request or event notification is invalid; for example,
a request is invalid XML (400), or not understood (500). Package
responses are carried in 200 response or REPORT message bodies. This
package's response codes are defined in Section 6.2.1.
The schema uses the "connection-id" and "conf-id" attributes which
are imported from the schema defined in the core Control Framework
[11].
5.3. Common XML Support
The Control Framework requires a Control Package definition to
specify if the attributes for media dialog or conference references
are required.
This package requires that the XML Schema in Section 16.1 of [11]
MUST be supported for media dialogs and conferences.
5.4. CONTROL Message Body
A valid CONTROL body message MUST conform to the schema defined in
Section 8 and described in Section 6. XML messages appearing in
CONTROL messages MUST contain one of the elements described in
Section 6.1.
5.5. REPORT Message Body
A valid REPORT body MUST conform to the schema defined in Section 8
and described in Section 6. XML messages appearing in REPORT
messages MUST contain a <response> (Section 6.2.1), or a
(notification) <event> element (Section 6.3.2).
Miniero, et al. Expires August 15, 2008 [Page 5]
Internet-Draft BFCP Control Package February 2008
6. Element Definitions
This section defines the XML messages for this control package.
[Editors Note: since XML Schema may not be able to express all
constraints expressed in these definitions, in cases where there is a
difference in constraints, the definitions in the section take
priority.]
6.1. Requests
The following request elements are defined:
<moderateconference>: create and configure a new BFCP conference,
associated with an existing framework conference instance to
moderate - see Section 6.1.1 for details;
<unmoderateconference>: destroy a BFCP conference, thus stopping the
moderation of the associated framework conference instance - see
Section 6.1.2 for details;
<addfloor>: add and configure a new floor to an existing BFCP
conference - see Section 6.1.3 for details;
<modifyfloor>: modify the configuration of a currently handled floor
in an existing BFCP conference - see Section 6.1.4 for details;
<removefloor>: remove a currently handled floor from an existing
BFCP conference - see Section 6.1.5 for details;
<addparticipant>: add a floor participant to a BFCP conference - see
Section 6.1.6 for details;
<removeparticipant>: remove a floor participant from a BFCP
conference - see Section 6.1.7 for details.
6.1.1. <moderateconference>
<moderateconference> is used in a request by the AS to moderate an
existing conference instance, by associating to it a new, properly
configured, BFCP conference.
The <moderateconference> element has the following attributes:
Miniero, et al. Expires August 15, 2008 [Page 6]
Internet-Draft BFCP Control Package February 2008
conf-id: string indicating the name of the conference to moderate.
The conference MUST be known by the receiving entity or else a 404
'Conference does not exist' package level error will be generated.
This attribute is mandatory.
bfcp-conf-id: string (an unsigned integer) indicating a unique name
for the BFCP conference. If this attribute is not specified, the
MS creates a unique name for the BFCP conference. The value is
used in subsequent references to the conference (e.g. as bfcp-
conf-id in a <response>). When present in a <moderateconference>
request, the new value of this attribute MUST be unique or else a
403 'Conference already exists' package level error will be
reported. The attribute is optional.
Additionally, to configure the new BFCP conference, the
<moderateconference> element has the following child elements
defined:
<floor>: an element to configure a floor in the new BFCP conference
(see Section 6.4.1 for more details). This element only refers to
floors already available at creation time. New floors can still
be added subsequently by means of an <addfloor> request (see
Section 6.1.3). This element is optional.
<subscribe>: an element to request subscription to conference
events. (see Section 6.3.1 for more details). This element is
optional.
Multiple <floor> elements may be defined, in case several floors are
needed.
When a MS has finished processing a <moderateconference> request, it
MUST reply with an appropriate <response> element (Section 6.2.1).
6.1.2. <unmoderateconference>
<unmoderateconference> is used in a request by the AS to destroy a
BFCP conference, thus stopping the moderatation of the associated
existing framework conference instance. A successful processing of
this request does NOT result in a destruction of the associated media
conference: it only results in the media conference not being
moderated by means of BFCP anymore. The actual destruction of the
media conference itself is accomplished through the means provided in
[13].
The <unmoderateconference> element has the following attributes:
Miniero, et al. Expires August 15, 2008 [Page 7]
Internet-Draft BFCP Control Package February 2008
bfcp-conf-id: string indicating the name of the BFCP conference to
destroy. The conference MUST be known by the receiving entity or
else a 404 'Conference does not exist' package level error will be
generated. This attribute is mandatory.
The <unmoderateconference> element does not specify any child
elements.
When a MS has finished processing an <unmoderateconference> request,
it MUST reply with an appropriate <response> element (Section 6.2.1).
6.1.3. <addfloor>
<addfloor> is used in a request by the AS to add one or more floors
to an existing BFCP conference instance.
The <addfloor> element has the following attributes:
bfcp-conf-id: string indicating the name of the BFCP conference to
add the floor(s) to. The conference MUST be known by the
receiving entity or else a 404 'Conference does not exist' package
level error will be generated. This attribute is mandatory.
Additionally, to configure the new floor(s), the <addfloor> element
has the following child elements defined:
<floor>: an element to configure a new floor in the specified BFCP
conference (see Section 6.4.1 for more details). This element is
mandatory.
Multiple <floor> elements may be defined, in case several floors are
to be added at the same time.
When a MS has finished processing a <addfloor> request, it MUST reply
with an appropriate <response> element (Section 6.2.1).
6.1.4. <modifyfloor>
<removefloor> is used in a request by the AS to remove an existing
floor from the BFCP conference instance it is in. A successful
processing of this request does NOT result in a destruction of the
associated resource (or set of resources): it only results in the
associated resource not being moderated by means of BFCP anymore.
The actual destruction of the resource (in case it is directly
handled and manipulated by the MS itself) is accomplished through the
means provided in [13].
The <removefloor> element has the following attributes:
Miniero, et al. Expires August 15, 2008 [Page 8]
Internet-Draft BFCP Control Package February 2008
bfcp-conf-id: string indicating the name of the BFCP conference to
remove the floor from. The conference MUST be known by the
receiving entity or else a 404 'Conference does not exist' package
level error will be generated. This attribute is mandatory.
bfcp-floor-id: string indicating the name of the BFCP floor to
remove. The floor MUST be known by the receiving entity or else a
404 'Floor does not exist' package level error will be generated.
This attribute is mandatory.
The <removefloor> element does not specify any child elements.
When a MS has finished processing a <removefloorfloor> request, it
MUST reply with an appropriate <response> element (Section 6.2.1).
6.1.5. <removefloor>
<modifyfloor> is used in a request by the AS to modify the
configuration of a floor in an existing BFCP conference instance.
The <modifyfloor> element has the following attributes:
bfcp-conf-id: string indicating the name of the BFCP conference to
modify the floor's in. The conference MUST be known by the
receiving entity or else a 404 'Conference does not exist' package
level error will be generated. This attribute is mandatory.
bfcp-floor-id: string indicating the name of the BFCP floor to
modify the floor. The floor MUST be known by the receiving entity
or else a 404 'Floor does not exist' package level error will be
generated. This attribute is mandatory.
Additionally, to modify the configuration of the floor, the
<modifyfloor> element has the following child elements defined:
<floor>: an element to configure the specified floor in the
specified BFCP conference (see Section 6.4.1 for more details).
This element is mandatory.
It is an error if the provided <floor> element conflicts with the
BFCP floor identifier attribute.
When a MS has finished processing a <modifyfloor> request, it MUST
reply with an appropriate <response> element (Section 6.2.1).
Miniero, et al. Expires August 15, 2008 [Page 9]
Internet-Draft BFCP Control Package February 2008
6.1.6. <addparticipant>
TBD. (is this really needed? there's RFC4583 for that...)
6.1.7. <removeparticipant>
TBD. (is this really needed? there's RFC4583 for that...)
6.2. Responses
All responses to the previously described requests are specified in a
<response> element. This element may be contained in the body either
of a REPORT framework message or in a 200 framework message.
6.2.1. <response>
Reponses to requests are indicated by a <response> element.
The <response> element has the following attributes:
status: numeric code indicating the response status. This attribute
is mandatory.
reason: string specifying a human readable description of the reason
for the response status. This attribute is optional.
bfcp-conf-id: string identifying the BFCP conference the request
referred to. This attribute is optional.
bfcp-floor-id: string identifying the BFCP floor the request
referred to. This attribute is optional.
The following status codes are defined:
+------+-------------+
| code | description |
+------+-------------+
| 200 | OK |
| 4xx | whatever |
+------+-------------+
Table 1: <response> Status codes
TBD. Add all error codes and their meanings
Miniero, et al. Expires August 15, 2008 [Page 10]
Internet-Draft BFCP Control Package February 2008
6.3. Notifications
In case the a controlling client is interested in receiving events
regarding a BFCP conference, a notification mechanism is provided in
the package. The client requests subscription to such events by
adding a <subscribe> child element to the <moderateconference>
request, whereas the MS triggers the related events in subsequent
REPORT messages. Event notifications are then delivered using the
<event> element.
6.3.1. <subscribe>
BFCP event notifications are defined when a controlling client
subscribes to notifications for BFCP-related events using the
<subscribe> element in a <moderateconference> request.
The <subscribe> element has no attributes, but has the following
child elements defined:
<notify>: contains the following attributes:
name a string indicating the name of the event to be notified.
The attribute is mandatory.
Multiple <notify> elements may be specified.
The MS would then use the <event> element to send notifications to
the controlling client.
6.3.2. <event>
Delivery of events the AS subscribed for is accomplished by means of
an <event> element.
The <event> element has the following attributes:
name: string indicating the name of the BFCP event. This attribute
is mandatory.
bfcp-conf-id: string identifying the BFCP conference the event
happened in. This attribute is mandatory.
Additionally, to provide the AS with details upon the event, the
<event> element has the following child elements defined:
TBD. Elaborate the notification mechanism.
Miniero, et al. Expires August 15, 2008 [Page 11]
Internet-Draft BFCP Control Package February 2008
6.4. Floors Manipulation
Floors are defined as tokens associated with a resource, or set of
resources, in order to moderate the access to their functionality by
users. This introduces the need for a mechanism in the package to
properly take care of this kind of association, especially when
dealing about resources directly manipulated by the Media Server
(e.g. andio and video).
Let's consider the following figure, which presents the view of an
audio conference with three participants, and the related media
labels associated with each participant's media stream:
MS
+---------------+
UAC A | | UAC B
o-----------+--x x--+-----------o
a1b2c3 | | d4e5f6
| |
| x |
| | |
+-------+-------+
|
| g7h8i9
|
o
UAC C
Figure 1: Audio Conference with labels
Even if each participant sees a different label for the stream he has
with the mixer, the floor associated with the only available resource
in the conference (audio) is the same. This means that the package
needs to have a way to address each resource in the conference
according to how it is defined in [13], e.g. "associate media 'audio'
with floor 11". Once a participant's media stream is attached to the
resource, the related label is consequently associated with the floor
as specified in [9]. Figure 2 depicts such the case where all the
participants have been attached to the mix.
Miniero, et al. Expires August 15, 2008 [Page 12]
Internet-Draft BFCP Control Package February 2008
MS
+---------------+
UAC A | | UAC B
o-----------+--+~~>[ ]<~~+--+-----------o
a1b2c3 | ^ | d4e5f6
(floor 11) | | | (floor 11)
| + |
| | |
+-------+-------+
|
| g7h8i9
| (floor 11)
o
UAC C
Figure 2: Audio Conference with labels and floors
The same approach can be considered when dealing with different
floors associated with one or more different resources, e.g.
conferences with an audio and a video stream, conferences with two
different audio streams, and so on. Each floor needs to be
unambiguously associated with a subset of the available resources
(e.g. floor 11 is audio1 and floor 22 is video, or floor 11 is audio1
while floor 22 is audio2, or floor 11 is audio1 AND audio2 AND
video2, and so on).
To achieve this, each floor, together with its configuration, is
defined in the package by the <floor> element.
6.4.1. <floor>
The <floor> element is used in the package to configure a floor in a
BFCP conference. It addresses all the relevant settings for a floor,
including the resource (or, again, set of resources) it must be
associated with, the maximum number of users that can be granted the
floor at the same time, the maximum number of requests the same
participant can place for this floor at the same time, and the
default policy the FCS considers for incoming requests about the
floor.
The <floor> element has the following attributes:
bfcp-floor-id: string indicating the name of the BFCP floor. This
attribute is optional.
Miniero, et al. Expires August 15, 2008 [Page 13]
Internet-Draft BFCP Control Package February 2008
<media>: an element indicating the type of media associated with the
floor, i.e. the resource associated with the floor, as defined in
[13]. The string might be a comma-separated list in case the
floor is associated with more than one resource (e.g.
media="audio,video"). This element is mandatory.
<max-users>: an element indicating the maximum number of users that
can be granted this floor at the same time: this basically sets
the size of the granted floor queue. In case all the queue slots
have already been granted, subsequent requests are put on hold.
This element is optional: if missing, the default value (max-
users="1") is used.
<max-requests>: an element indicating the maximum number of requests
each user can place for the floor before being granted it. This
element is optional: if missing, the default value (max-
requests"="1) is used.
<policy>: an element indicating the default policy the FCS must take
whenever receiving requests for this floor and the chair is
missing. In fact, in case a chair is involved, the request is
forwarded to him, which then takes a decision about it. The
policy can be an 'autodeny' (deny all the requests for this
floor), 'autoaccept' (accept all the requests for this floor) or
'ignore' (ignore all the requests for this floor and put them on
ice, waiting for a chair to appear) policy. This element is
optional: if missing, the default value (policy="autoaccept") is
used.
The "bfcp-floor-id" attribute has different roles according to the
request the <floor> element is part of. The behaviour of the package
changes accordingly. Specifically:
<moderateconference|addfloor>: if the attribute is not specified,
the MS creates a unique name for the BFCP floor. The value is
used in subsequent references to the conference (e.g. as bfcp-
floor-id in a <modifyfloor>). The new value of this attribute
MUST be unique or else a 403 'Floor already exists' package level
error will be reported.
<modifyfloor>: if the attribute is not specified, the value of the
attribute in the father element is used. If it is specified,
instead, it must not conflict with the value of the attribute in
the father element, otherwise it is an error.
TBD. Elaborate the floor mechanism.
Miniero, et al. Expires August 15, 2008 [Page 14]
Internet-Draft BFCP Control Package February 2008
7. Examples
TBD.
8. Formal Syntax
TBD.
9. Security Considerations
TBD.
10. IANA Considerations
TBD.
11. Acknowledgements
TBD.
12. References
[1] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[4] 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.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004.
Miniero, et al. Expires August 15, 2008 [Page 15]
Internet-Draft BFCP Control Package February 2008
[7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[8] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006.
[9] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
November 2006.
[10] Levin, O. and G. Camarillo, "The Session Description Protocol
(SDP) Label Attribute", RFC 4574, August 2006.
[11] Boulton, C., "A Control Framework for the Session Initiation
Protocol (SIP)", draft-ietf-mediactrl-sip-control-framework-00
(work in progress), September 2007.
[12] Boulton, C., Melanchuk, T., and S. McGlashan, "A Basic
Interactive Voice Response (IVR) Control Package for the
Session Initiation Protocol (SIP)",
draft-boulton-ivr-control-package-05 (work in progress),
November 2007.
[13] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A
Conference Control Package for the Session Initiation Protocol
(SIP)", draft-boulton-conference-control-package-03 (work in
progress), November 2007.
[14] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A
VoiceXML Interactive Voice Response (IVR) Control Package for
the Session Initiation Protocol (SIP)",
draft-boulton-ivr-vxml-control-package-03 (work in progress),
November 2007.
Authors' Addresses
Lorenzo Miniero
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: lorenzo.miniero@unina.it
Miniero, et al. Expires August 15, 2008 [Page 16]
Internet-Draft BFCP Control Package February 2008
Alessandro Amirante
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: alessandro.amirante@unina.it
Tobia Castaldi
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: tobia.castaldi@unina.it
Simon Pietro Romano
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: spromano@unina.it
Miniero, et al. Expires August 15, 2008 [Page 17]
Internet-Draft BFCP Control Package February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Miniero, et al. Expires August 15, 2008 [Page 18]