Network Working Group L. Tian
Internet-Draft Q. Sun
Expires: December 28, 2007 Huawei Technologies
June 26, 2007
Session Initiation Protocol (SIP) INVITE with Conference Info
draft-linyi-sipping-invite-with-conf-info-02
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 December 28, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Tian & Sun Expires December 28, 2007 [Page 1]
Internet-Draft invite with conference info June 2007
Abstract
This specification defines a mechanism that allows a SIP User Agent
Client (UAC) to provide a conference server with the initial
conference information and policy using an INVITE-contained
conference-info.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 5
4. INVITE: Sending conference-info to Conference Server . . . . . 6
4.1. Conference-Info Format . . . . . . . . . . . . . . . . . . 6
4.1.1. Conference-Info Format derived from Conference
State Package . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Conference-Info Format derived from XCON Data Model . 7
4.2. UAC Procedures . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. re-INVITE Request Generation . . . . . . . . . . . . . 9
4.3. Conference Server Procedures . . . . . . . . . . . . . . . 9
4.3.1. re-INVITE Request Handling . . . . . . . . . . . . . . 10
5. INVITE: Sending URI-List with conference-info to
Conference Server . . . . . . . . . . . . . . . . . . . . . . 11
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Creation of Conference with initial conference-info . . . 12
6.2. Creation of a Conference with initial URI-List and
conference-info . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. MIME Information . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. History of change . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Tian & Sun Expires December 28, 2007 [Page 2]
Internet-Draft invite with conference info June 2007
1. Introduction
Section 5.4 of RFC 4579 [1] describes how to create a conference
using ad-hoc SIP methods. The client sends an INVITE request to a
conference factory URI and receives the actual conference URI, which
contains the "isfocus" feature tag, in the Contact header field of a
response - typically a 200 (OK) response.
This specification extends the above mechanim to allow UAC to be able
to provide the Conference Server with the initial conference
information and policy (referred as conference-info below).
This specification further provides a mechanism for Conference Server
to distribute the conference-info generated from ad hoc conference
creation request as the history information to invitees.
The mechanism defined in this specification can be used either
standalone or together with other mechanisms, e.g. URI-List
conferencing mechanism defined in RFC XXX {URI List Conferencing} [2]
Tian & Sun Expires December 28, 2007 [Page 3]
Internet-Draft invite with conference info June 2007
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]
This document uses the conferencing terminology defined in RFC 4353
[9] "conferencing Framework".
Tian & Sun Expires December 28, 2007 [Page 4]
Internet-Draft invite with conference info June 2007
3. Requirements Analysis
RFC 4579 [1] defines a mechanism to provide the conference server
with the initial set of participants in a single operation during the
ad hoc conference creation. In addition the invoker may want to
provide simple conference information and policy referred as
conference-info below, for example the subject and maximum numbers of
participants, for an ad hoc conference in the same operation. In ad
hoc conference scenario they rarely desire to manipulate the
conference policy, whether before the conference is created or during
the conference.
RFC XXX {URI List Conferencing} [2] defines a mechanism for
Conference Server to provide URI-List history to invitees by
including a 'recipient-list-history' body which contains the
manipulated list of invitees. The same principle could be applied to
conference-info. When Conference Server sends INVITE to invitees,
e.g. triggered by REFER request or URI-List conference creation, the
Conference Server can provide them with the conference-info as
history information. This will help invitees to determine whether to
join this conference which may fall into their interest.
In current art when the invitees get an INVITE request with 'isfocus'
feature tag they may subscribe to the conference event package as
defined in RFC 4575 [4] and get notification before joining.
Consider the fact that the main criteria for invitees to determine
whether to join a conference may be some simple information, e.g.
subject, it is more efficient and convenient for invitees to get
information from the incoming INVITE rather than using subscription
to the Conference Event Package. This mechanism could be considered
as complementary to conference event package subscription mechanism.
Invitees can also use confernce event package subscription mechanism
to get more detail information.
The requirements to support invitation with conference-info may be
summarized as follows:
REQ 1: The conference mechanism MUST allow the invoker to provide
the Conference Server with the initial conference information and
policy in order to create an ad-hoc conference via one operation.
REQ 2: The conference mechanism MUST allow the Conference Server
to distribute the conference information and policy to invitees
contained in the URI-List.
Tian & Sun Expires December 28, 2007 [Page 5]
Internet-Draft invite with conference info June 2007
4. INVITE: Sending conference-info to Conference Server
RFC 4575 [4] defines a Conference Event Package for tightly coupled
conferences using the Session Initiation Protocol (SIP) events
framework, along with a data format used in notifications for SIP
specific conferencing. RFC XXX {XCON Data Model} [5] extends the
data format to support more call signaling protocols besides SIP and
cover the functionality defined in the XCON conferencing framework.
A sub-set of both data formats can be used to represent conference-
info, e.g. <conference-description> and <maximum-user-count>.
The conference-info can be included in the body of initial SIP INVITE
request to create an ad-hoc conference. Hence it can be included in
the follow-up SIP INVITE requests so that invitees are aware.
4.1. Conference-Info Format
The sub set of data format defined in RFC 4575 [4] and extended in
RFC XXX {XCON Data Model} [5] can be used to represent the
conference-info which could be carried in SIP INVITE method. The
amount of data MUST be limited to avoid overload of SIP messages.
The <conference-info> element has three attributes 'entity', 'state'
and 'version'. The 'entity' and 'version' attributes MUST be
included. The 'state' attribute is MAY be included and the default
value is "full".
In this specification, there are some restrictions for attributes of
<conference-info> element as follow:
o 'entity': In initial INVITE request from invoker the value MAY be
any URI and MUST be ignored by Conference Server. In subsequent
INVITE requests from Conference Server the value MUST be the
conference URI that identifies the conference created by the
Conference Server. The invitees can subscribe this URI for
receiving Conference Event Package.
o 'state': This attribute MAY not be present in all INVITE requests.
If it is present, it MUST be ignored by the Conference Server and
invitees.
o 'version': This attribute MAY contain any version number and MUST
be ignored by the Conference Server and invitees.
Tian & Sun Expires December 28, 2007 [Page 6]
Internet-Draft invite with conference info June 2007
4.1.1. Conference-Info Format derived from Conference State Package
Following is the sub set of data format defined in RFC 4575 [4]
representing the conference-info. Other elements or attributes
defined in RFC 4575 [4] SHOULD NOT included in initial INVITE request
and subsequent INVITE requests to invitees.
<conference-info>
|
|--<conference-description>
| |--<display-text>
| |--<subject>
| |--<free-text>
| |--<keywords>
| |
| |--<service-uris>
| | |--<entry>
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| |
| |--<maximum-user-count>
Figure 1: Conference-Info Format derived from Conference State
Package
4.1.2. Conference-Info Format derived from XCON Data Model
Following is the sub set of data format defined in RFC XXX {XCON Data
Model} [5] representing the conference-info. Other elements or
attributes defined in RFC XXX {XCON Data Model} [5] SHOULD NOT
included in initial INVITE request and subsequent INVITE requests to
invitees.
Tian & Sun Expires December 28, 2007 [Page 7]
Internet-Draft invite with conference info June 2007
<conference-info>
|
|--<conference-description>
| |--<display-text>
| |--<subject>
| |--<free-text>
| |--<keywords>
| |--<allow-sidebars>
| |
| |--<service-uris>
| | |--<entry>
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | |--<H323>
| | | |--<H.323-alias>
| | | |--<H.323-URI>
| | |--<PSTN-ISDN>
| | | |--<phone number>
| |
| |--<maximum-user-count>
|
|--<conference-state>
| |--<allow-conference-event-subscription>
|
|--<floor-information>
| |--<allow-floor-events>
| |--<floor-request-handling>
| |--<conference-floor-policy>
| | |--<floor>
| | | |--<media-types>
| | | |--<algorithm>
| | | |--<max-floor-users>
| | | |--<chair-id>
Figure 2: Structure of Conference-Info derived from XCON Data Model
4.2. UAC Procedures
A UAC that wants to include the initial conference-info in its
initial INVITE request MUST add a body whose disposition type is
'conference-info' as defined in section xxx of this specification.
Additionally, the UAC MUST include the 'conference-info-invite'
option-tag, which is registered with the IANA in Section xxx in a
Require header field. The UAC sends this INVITE request to the
conference factory URI.
A 200 (OK) response means that the conference was created
Tian & Sun Expires December 28, 2007 [Page 8]
Internet-Draft invite with conference info June 2007
successfully, that the UAC that generated the INVITE request is in
the conference, and that the server understood the conference
information.
4.2.1. re-INVITE Request Generation
The previous section has specified how to include the conference
information in an initial INVITE request to a conference server.
Once the INVITE-initiated dialog between the UAC and the Conference
Server has been established, the UAC can send re-INVITE requests to
the conference server to, modify the characteristics of the media
exchanged with the server.
There are no semantics associated with conference-info bodies in re-
INVITE requests. Therefore, UACs MUST NOT include conference-info
bodies in re-INVITE requests sent to a conference server (although it
may become useful at some future time and future extentions may
define them).
4.3. Conference Server Procedures
Conference Server that is able to receive and process INVITE requests
with a 'conference-info' body MUST include a 'conference-info-invite'
option-tag in a Supported header field when responding to OPTIONS
requests.
On reception of an INVITE request containing a 'conference-info' body
as described in Section 3, a conference server MUST follow the rules
described in RFC 4579 [1] to create ad-hoc conference.
If <maximum-user-count> element is present, the Conference Server
MUST reject the requests to add new participants to the conference
when the number of participants has reached the number specified in
this element. The Conference Server MUST ignore 'state' attribute if
it is present. The Conference Server MUST ignore 'version'
attribute.
The Conference Server MUST include the same conference-info from
incoming INVITE request to the invitees as the history information
using an INVITE-contained conference-info request. The Conference
Server MUST NOT add new elements to history information.
If the Conference Server includes conference-info history in an
outgoing INVITE request, it MUST include a Content-Disposition header
field (which is specified in RFC 2183 [6] ) with the value set to
'conference-info-history' and a 'handling' parameter (as specified in
RFC 3204 [7] ) set to "optional".
Tian & Sun Expires December 28, 2007 [Page 9]
Internet-Draft invite with conference info June 2007
4.3.1. re-INVITE Request Handling
There are no semantics associated with conference-info bodies in re-
INVITE requests. Therefore, a Conference Server receiving a re-
INVITE request with a conference-info body and, consequently, a
'conference-info-invite' option-tag, following standard SIP
procedures, MUST reject it with a 420 (Bad Extension), which carries
an Unsupported header field listing the 'conference-info-invite'
option-tag.
This is because the resource identified by the conference URI does
not actually support this extension. On the other hand, the
resource identified by the conference factory URI does support
this extension and, consequently, would include the 'conference-
info-invite' option-tag in, for example, responses to OPTIONS
requests.
Tian & Sun Expires December 28, 2007 [Page 10]
Internet-Draft invite with conference info June 2007
5. INVITE: Sending URI-List with conference-info to Conference Server
The mechanism defined in section 4 of this specification can be used
together with other mechanisms, e.g. URI-List conferencing mechanism
defined in RFC XXX {URI List Conferencing} [2] . The initial INVITE
request can carry a 'multipart/mixed' body composed of three bodies:
o 'application/sdp' body: describes the session;
o 'application/resource-lists+xml' body: describes the list of
target URIs;
o 'application/conference-info+xml' body: contains the conference
information.
The UAC and Conference Server MUST follow the procedures defined in
RFC XXX {URI List Conferencing} [2] and section 4 of this
specification respectively. In addition, the UAC MUST ensure the
number of URIs in the URI-List will not exceed the number specified
in <maximum-user-count> element when it is present. A Conference
Server receiving a INVITE request with a URI-List body and a
conference-info body where the number of URIs exceed maximum user
count, consequently, rejects it with a 403 (Forbidden).
Tian & Sun Expires December 28, 2007 [Page 11]
Internet-Draft invite with conference info June 2007
6. Example
6.1. Creation of Conference with initial conference-info
Figure 3 shows an example of ad-hoc conference creation with initial
conference-info. A UAC sends an INVITE request F1 that contains SDP
body and conference-info to the Conference Server. The Conference
Server answers with a 200 (OK) response. Then Conference Server is
requested to add new participant Bob to the specified conference
using REFER method. The UAC sends a REFER request F3 to the
conference URI with a Refer-To containing the URI of Bob. The
Conference Server sends an INVITE request F7 to Bob containing the
conference-info history. Then Bob knows the conference-info of this
specific conference, such as subject, directly when he receives the
INVITE request F7 and decides to join it.
Alice Conference Server Bob
| | |
| F1:INVITE sip:Conf-Factory with initial conference-info |
|----------------------------->| |
| F2:200 OK Contact:Conf-ID;isfocus |
|<-----------------------------| |
| | |
| F3:REFER sip:Conf-ID Refer-To:Bob |
|----------------------------->| |
| F4:202 Accepted | |
|<-----------------------------| |
| F5:NOTIFY (Trying) | |
|<-----------------------------| |
| F6:200 OK F4 | |
|----------------------------->| |
| | F7:INVITE |
| |------------------------------>|
| | F8:200 OK |
| |<------------------------------|
| | |
Figure 3: Creation of a conference with initial conference-info using
ad-hoc SIP method
Figure 4 shows an example of the INVITE request F1, which carries a
'multipart/mixed' body composed of two other bodies:
o 'application/sdp' body: describes the session;
o 'application/conference-info+xml' body: contains the initial
conference-info.
Tian & Sun Expires December 28, 2007 [Page 12]
Internet-Draft invite with conference info June 2007
INVITE sip:32132219811205@conf.example.com SIP/2.0
Via: SIP/2.0/TCP beijing.example.com
;branch=z9hG4bKa38ssa8s
Max-Forwards: 70
To: "Conference Factory" <sip:32132219811205@conf.example.com>
From: Alice <sip:alice@beijing.example.com>;tag=13323
Call-ID: b01766e67c4b48af234
CSeq: 1 INVITE
Contact: <sip:alice@beijing.example.com>
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Require: conference-info-invite
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: ...
--boundary1
Content-Type: application/sdp
(SDP not shown)
--boundary1
Content-Type: application/conference-info+xml
Content-Disposition: conference-info
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sip:32132219811205@conf.example.com"
state="full" version="0">
<conference-description>
<subject>Agenda: This month's goals</subject>
<service-uris>
<entry>
<uri>http://www.example.com/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
<maximum-user-count>10</maximum-user-count>
</conference-description>
</conference>
Figure 4: Initial INVITE request received at the Conference Server
Figure 5 shows an example of the INVITE request F7, which carries a
'multipart/mixed' body composed of three other bodies:
Tian & Sun Expires December 28, 2007 [Page 13]
Internet-Draft invite with conference info June 2007
o 'application/sdp' body: describes the session;
o 'application/conference-info+xml' body: contains the conference
info history.
Tian & Sun Expires December 28, 2007 [Page 14]
Internet-Draft invite with conference info June 2007
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKt34932hw
Max-Forwards: 70
To: <sip:bob@shanghai.example.com>
From: <sip:32132219811205@conf.example.com>
Call-ID: 849392fklgl43
CSeq: 1 INVITE
Contact: <sip:32132219811205@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Require: conference-info-invite
Supported: replaces, join
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: ...
--boundary1
Content-Type: application/sdp
(SDP not shown)
--boundary1
Content-Type: application/conference-info+xml
Content-Disposition: conference-info-history; handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sip:conf01@conf.example.com"
state="full" version="0">
<conference-description>
<subject>Agenda: This month's goals</subject>
<service-uris>
<entry>
<uri>http://www.example.com/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
<maximum-user-count>10</maximum-user-count>
</conference-description>
</conference-info>
6.2. Creation of a Conference with initial URI-List and conference-info
Figure 6 shows an example of ad-hoc conference creation with initial
URI-List and conference-info. A UAC sends an INVITE request F1 that
contains initial participants list and conference-info to the
Conference Server. The Conference Server answers with a 200 (OK)
response. Then Conference Server generates an INVITE request to each
of the participants identified by the URIs included in the URI-list.
Tian & Sun Expires December 28, 2007 [Page 15]
Internet-Draft invite with conference info June 2007
The Conference Server includes a manipulated URI-list and conference-
info history in each of the outgoing INVITE requests.
Alice Conference Server Bob Alice Carol
| | | | |
| F1:INVITE with URI-List and conference-info | |
|---------------------->| | | |
| F2:200 OK | | | |
|<----------------------| | | |
| Conference Server distributes URI-List and confernce info history
| | F3:INVITE | | |
| |---------------->| | |
| | F4:200 OK | | |
| |<----------------| | |
| | F5:INVITE | | |
| |------------------------->| |
| | F6:200 OK | | |
| |<-------------------------| |
| | F7:INVITE | | |
| |---------------------------------->|
| | F8:200 OK | | |
| |<----------------------------------|
| | | | |
Figure 7: Creation of a conference with initial URI-List and
conference-info
Figure 8 shows an example of the INVITE request F1, which carries a
'multipart/mixed' body composed of three other bodies:
o 'application/sdp' body: describes the session;
o 'application/resource-lists+xml' body: contains the list of target
URIs
o 'application/conference-info+xml' body: contains the conference
information.
INVITE sip:32132219811205@conf.example.com SIP/2.0
Via: SIP/2.0/TCP beijing.example.com
;branch=z9hG4bKa38ssa8s
Max-Forwards: 70
To: "Conf Factory" <sip:32132219811205@conf.example.com>
From: Alice <sip:alice@beijing.example.com>;tag=13323
Call-ID: b01766e67c4b48af234
CSeq: 1 INVITE
Tian & Sun Expires December 28, 2007 [Page 16]
Internet-Draft invite with conference info June 2007
Contact: <sip:alice@beijing.example.com>
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Require: recipient-list-invite, conference-info-invite
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: ...
--boundary1
Content-Type: application/sdp
(SDP not shown)
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copyControl">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
--boundary1--
--boundary1
Content-Type: application/conference-info+xml
Content-Disposition: conference-info
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sip:32132219811205@conf.example.com"
state="full" version="0">
<conference-description>
<subject>Agenda: This month's goals</subject>
<service-uris>
<entry>
Tian & Sun Expires December 28, 2007 [Page 17]
Internet-Draft invite with conference info June 2007
<uri>http://www.example.com/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
<maximum-user-count>10</maximum-user-count>
</conference-description>
</conference-info>
Figure 8: Initial INVITE request received at the Conference Server
The INVITE requests F3, F5, and F7 are similar in nature. Figure 9
shows an example of the INVITE request F3, which carries a
'multipart/mixed' body composed of three other bodies:
o 'application/sdp' body: describes the session;
o 'application/resource-lists+xml' body: contains the list of target
URIs manipulated by Conference Server
o 'application/conference-info+xml' body: contains the history
conference-info.
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKt34932hw
Max-Forwards: 70
To: <sip:bob@shanghai.example.com>
From: Conference Server <sip:conf01@conf.example.com>;tag=234332
Call-ID: 849392fklgl43
CSeq: 1 INVITE
Contact: <sip:conf01@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Require: recipient-list-invite, conference-info-invite
Supported: replaces, join
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: ...
--boundary1
Content-Type: application/sdp
(SDP not shown)
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
Tian & Sun Expires December 28, 2007 [Page 18]
Internet-Draft invite with conference info June 2007
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
--boundary1--
--boundary1
Content-Type: application/conference-info+xml
Content-Disposition: conference-info-history; handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sip:conf01@conf.example.com"
state="full" version="1">
<conference-description>
<subject>Agenda: This month's goals</subject>
<service-uris>
<entry>
<uri>http://www.example.com/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
<maximum-user-count>10</maximum-user-count>
</conference-description>
</conference-info>
Tian & Sun Expires December 28, 2007 [Page 19]
Internet-Draft invite with conference info June 2007
7. Security Considerations
SIP Conferencing generally have authorization rules about who can or
cannot join a conference, what type of media can or cannot be used,
etc. This information is used by the focus to admit or deny
participation in a conference. It is RECOMMENDED that these types of
authorization rules be used to provide security for a SIP conference.
For this authorization information to be used, the focus needs to be
able to authenticate potential participants. Normal SIP mechanisms
including Digest authentication and certificates can be used. These
conference specific security requirements are discussed further in
the requirements and framework documents.
This specification defines a mechanism to setup ad hoc SIP
conferences using a INVITE-contained conference-info which may
contain additional policy for focus to control the conferences.
Implementations of conference servers MUST follow the policy
contained in conference-info.
The mechanism defined in this specification can be used together with
URI-List Service. The Framework and Security Considerations for SIP
URI-List Services (which is documented in RFC XXXX [8] ) discusses
issues related to SIP URI-list services. Given that a conference
server sending INVITE requests to a set of users acts as an URI-list
service, implementations of conference servers that handle lists MUST
follow the security-related policy in RFC XXXX [8] . These rules
include mandatory authentication and authorization of clients, and
opt-in lists.
Tian & Sun Expires December 28, 2007 [Page 20]
Internet-Draft invite with conference info June 2007
8. IANA Considerations
This document defines the 'conference-info-invite' SIP option-tag.
It should be registered in the Option Tags subregistry under the SIP
parameter registry. The following is the description to be used in
the registration.
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| conference-info-invite | The body contains the | [RFC XXXX]|
| | conference information and | |
| | policy for a specific | |
| | conference. | |
+------------------------+------------------------------+-----------+
Figure 9: Registration of the 'conference-info-invite' Option-Tag in
SIP.
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| conference-info | The body contains the | [RFC XXXX]|
| | conference information and | |
| | policy for a specific | |
| | conference. | |
+------------------------+------------------------------+-----------+
Figure 10: Registration of the 'conference-info' Disposition Type.
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| conference-info-history| The body contains the history| [RFC XXXX]|
| | conference information and | |
| | policy for a specific | |
| | conference. | |
+------------------------+------------------------------+-----------+
Figure 9: Registration of the 'conference-info-history' Disposition
Type.
Tian & Sun Expires December 28, 2007 [Page 21]
Internet-Draft invite with conference info June 2007
9. Acknowledges
Henning Schulzrinne, Spencer Dawkins, Even Roni, Oscar Novo and Peili
Xu provided useful comments on this document.
Tian & Sun Expires December 28, 2007 [Page 22]
Internet-Draft invite with conference info June 2007
10. MIME Information
The MIME type for the conference-info is: application/
conference-info+xml as defined in RFC 4575 [4]
Tian & Sun Expires December 28, 2007 [Page 23]
Internet-Draft invite with conference info June 2007
11. References
11.1. Normative References
[1] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents", RFC 4579,
August 2006.
[2] Camarillo, G. and A. Johnston, "Conference Establishment Using
Request-Contained Lists in the Session Initiation Protocol
(SIP)", RFC xxxx, January 2007.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[4] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[5] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference
Information Data Model for Centralized Conferencing (XCON)",
RFC xxxx, January 2007.
[6] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997.
[7] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M., and M. Zonoun, "Communicating Presentation
Information in Internet Messages: The Content-Disposition Header
Field", RFC 3204, December 2001.
[8] Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-06 (work in progress),
September 2006.
11.2. Informative References
[9] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
Tian & Sun Expires December 28, 2007 [Page 24]
Internet-Draft invite with conference info June 2007
Appendix A. History of change
This is the first version of this draft.
Tian & Sun Expires December 28, 2007 [Page 25]
Internet-Draft invite with conference info June 2007
Authors' Addresses
Linyi Tian
Huawei Technologies
Bantian Longgang
Shenzhen, Guandong 518129
P.R China
Phone: +86 755 28780808
Email: tianlinyi@huawei.com
Qian Sun
Huawei Technologies
Bantian Longgang
Shenzhen, Guandong 518129
P.R China
Phone: +86 755 28780808
Email: sunqian@huawei.com
Tian & Sun Expires December 28, 2007 [Page 26]
Internet-Draft invite with conference info June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
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).
Tian & Sun Expires December 28, 2007 [Page 27]