draft-ietf-xcon-examples-07.txt   draft-ietf-xcon-examples-08.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Intended status: Informational L. Miniero Intended status: Informational L. Miniero
Expires: April 28, 2011 Meetecho Expires: August 18, 2011 Meetecho
R. Presta R. Presta
S P. Romano S P. Romano
University of Napoli University of Napoli
October 25, 2010 February 14, 2011
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
draft-ietf-xcon-examples-07 draft-ietf-xcon-examples-08
Abstract Abstract
This document provides detailed call flows for the scenarios This document provides detailed call flows for the scenarios
documented in the Centralized Conferencing (XCON) Framework and the documented in the Centralized Conferencing (XCON) Framework and the
XCON Scenarios. The call flows document the use of the interface XCON Scenarios. The call flows document the use of the interface
between a conference control client and a conference control server between a conference control client and a conference control server
using the Centralized Conferencing Manipulation Protocol (CCMP). The using the Centralized Conferencing Manipulation Protocol (CCMP). The
objective is to provide a base reference for both protocol objective is to provide a base reference for both protocol
researchers and developers. researchers and developers.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on August 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 34, line 9 skipping to change at page 34, line 9
XCON-USERID in the "entity" attribute of the "userInfo" field, XCON-USERID in the "entity" attribute of the "userInfo" field,
without providing additional data. In fact, that data without providing additional data. In fact, that data
(including, for instance, Bob's SIP-URI to be used subsequently (including, for instance, Bob's SIP-URI to be used subsequently
for dial-out) would be obtained by referencing the extant for dial-out) would be obtained by referencing the extant
registration. The conference server ensures that Alice has the registration. The conference server ensures that Alice has the
appropriate authority based on the policies associated with that appropriate authority based on the policies associated with that
specific conference object to perform the operation. As specific conference object to perform the operation. As
mentioned before, a new Conference User Identifier is created for mentioned before, a new Conference User Identifier is created for
Bob, and the "userInfo" is used to update the conference object Bob, and the "userInfo" is used to update the conference object
accordingly. As already seen in Section 5.3, a placeholder accordingly. As already seen in Section 5.3, a placeholder
wildcard ("xcon-userid:AUTO_GENERATE@example.com" in the CCMP wildcard ("xcon-userid:AUTO_GENERATE_1@example.com" in the CCMP
messages below) is used for the "entity" attribute of the messages below) is used for the "entity" attribute of the
"userInfo" element, to be replaced by the actual XCON-USERID "userInfo" element, to be replaced by the actual XCON-USERID
later on; later on;
2. Bob is successfully added to the conference object, and an XCON- 2. Bob is successfully added to the conference object, and an XCON-
USERID is allocated for him ("xcon-userid:Bob@example.com"); this USERID is allocated for him ("xcon-userid:Bob@example.com"); this
identifier is reported in the response as part of the "entity" identifier is reported in the response as part of the "entity"
element of the returned "userInfo"; element of the returned "userInfo";
3. In the presented example, the call signaling to add Bob to the 3. In the presented example, the call signaling to add Bob to the
skipping to change at page 35, line 4 skipping to change at page 35, line 4
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID> <confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE@example.com"> <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<info:display-text>Bob</info:display-text> <info:display-text>Bob</info:display-text>
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri>mailto:bob.depippis@example.com</info:uri> <info:uri>mailto:bob.depippis@example.com</info:uri>
<info:display-text>Bob's email</info:display-text> <info:display-text>Bob's email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:bob83@example.com"> <info:endpoint entity="sip:bob83@example.com">
<info:display-text>Bob's laptop</info:display-text> <info:display-text>Bob's laptop</info:display-text>
</info:endpoint> </info:endpoint>
skipping to change at page 43, line 18 skipping to change at page 43, line 18
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confObjID>xcon:bobConf@example.com</confObjID> <confObjID>xcon:bobConf@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE@example.com"> <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:Alice83@example.com mailto:Alice83@example.com
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/> <info:endpoint entity="sip:alice_789@example.com"/>
</userInfo> </userInfo>
skipping to change at page 70, line 44 skipping to change at page 70, line 44
request the insertion of a further media stream in the sidebar request the insertion of a further media stream in the sidebar
(i.e. in this example an audio stream from Alice to Bob), the (i.e. in this example an audio stream from Alice to Bob), the
requestor has to provide a new <entry> element in the <available- requestor has to provide a new <entry> element in the <available-
media> field of the "sidebarByRefInfo". The mandatory "label" media> field of the "sidebarByRefInfo". The mandatory "label"
attribute of that new entry is filled with a dummy value attribute of that new entry is filled with a dummy value
"AUTO_GENERATE_1", but it will contain the real server-generated "AUTO_GENERATE_1", but it will contain the real server-generated
media stream identifier when the media stream is effectively media stream identifier when the media stream is effectively
allocated on the server side. Similarly, the mandatory "id" allocated on the server side. Similarly, the mandatory "id"
attribute in <media> element referring to the new sidebar audio attribute in <media> element referring to the new sidebar audio
stream under both Alice's and Bob's <endpoint> contains a stream under both Alice's and Bob's <endpoint> contains a
wildcard value, respectively "AUTO_GENERATED_2" and wildcard value, respectively "AUTO_GENERATE_2" and
"AUTO_GENERATED_3": those values will be replaced with the "AUTO_GENERATE_3": those values will be replaced with the
appropriated server-generated identifiers upon the creation of appropriated server-generated identifiers upon the creation of
the referred media stream. We are assuming the conferencing the referred media stream. We are assuming the conferencing
control server is able to recognize those dummy values as place- control server is able to recognize those dummy values as place-
holders. holders.
4. After validating the data, the conference server sends a 4. After validating the data, the conference server sends a
sidebarByRefResponse message. Based upon the contact information sidebarByRefResponse message. Based upon the contact information
provided for Bob by Alice, the call signaling to add Bob to the provided for Bob by Alice, the call signaling to add Bob to the
sidebar with the appropriate media characteristics is instigated sidebar with the appropriate media characteristics is instigated
through the Focus. Bob is notified of his addition to the through the Focus. Bob is notified of his addition to the
skipping to change at page 81, line 21 skipping to change at page 81, line 21
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[I-D.ietf-xcon-ccmp] [I-D.ietf-xcon-ccmp]
Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
"Centralized Conferencing Manipulation Protocol", "Centralized Conferencing Manipulation Protocol",
draft-ietf-xcon-ccmp-10 (work in progress), July 2010. draft-ietf-xcon-ccmp-11 (work in progress), October 2010.
13.2. Informative References 13.2. Informative References
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. Names", BCP 32, RFC 2606, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
skipping to change at page 82, line 9 skipping to change at page 82, line 9
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-20 Conferencing (XCON)", draft-ietf-xcon-common-data-model-23
(work in progress), October 2010. (work in progress), February 2011.
[I-D.ietf-mediactrl-call-flows] [I-D.ietf-mediactrl-call-flows]
Amirante, A., Castaldi, T., Miniero, L., and S. Romano, Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
"Media Control Channel Framework (CFW) Call Flow "Media Control Channel Framework (CFW) Call Flow
Examples", draft-ietf-mediactrl-call-flows-05 (work in Examples", draft-ietf-mediactrl-call-flows-05 (work in
progress), October 2010. progress), October 2010.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media [RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009. Server Control", RFC 5567, June 2009.
[I-D.ietf-mediactrl-mixer-control-package] [I-D.ietf-mediactrl-mixer-control-package]
McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
Control Package for the Media Control Channel Framework", Control Package for the Media Control Channel Framework",
draft-ietf-mediactrl-mixer-control-package-11 (work in draft-ietf-mediactrl-mixer-control-package-14 (work in
progress), February 2010. progress), January 2011.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Polycom Polycom
TX TX
US US
Email: mary.ietf.barnes@gmail.com Email: mary.ietf.barnes@gmail.com
 End of changes. 12 change blocks. 
15 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/