RFC 6504
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
Pages: 78
Informational
Informational
Part 4 of 4 – Pages 60 to 78
7.3. Private Messages
The case of private messages can be handled as a sidebar with just two participants, similar to the example in Section 7.1. Unlike the previous example, rather than using audio within the sidebar, Alice could just add an additional text-based media stream to the sidebar in order to convey her textual messages to Bob, while still viewing and listening to the main conference.
In this scenario, Alice requests to the conference server the creation of a private chat room within the main conference context (presented in Figure 19) in which the involved participants are just Bob and herself. This can be achieved through the following CCMP transaction (Figure 23). 1. Alice forwards a sidebarByValRequest/create message to the conference server with the main conference XCON-URI in the <confObjID> parameter and the desired sidebar conference object in the <sidebarByValInfo> field. In this way, a sidebar creation using user-provided conference information is requested from the conference server. Please note that, unlike the previous sidebar examples, in this case, a completely new conference object to describe the sidebar is provided: there is no cloning involved, while the <confObjID> still enforces the parent-child relationship between the main conference and the to-be-created sidebar. 2. The conference server, after checking Alice's rights and validating the conference object carried in the request, creates the required sidebar-by-val conference and a new XCON-URI for it. Instead of cloning the main conference object, as shown in Sections 7.1 and 7.2, the sidebar is created on the basis of the user-provided conference information. However, the parent relationship between the main conference and the newly created sidebar is still maintained by the conference server (as a consequence of the chosen CCMP request message type -- the sidebarByVal one) and it is reflected by the <sidebar-parent> element in the <sidebarByValInfo> element returned in the sidebarByValResponse message. Please notice that, according to the CCMP specification, the return of the created sidebar data in this kind of "success" response is not mandatory. 1. sidebarByValRequest/create message (Alice creates a private chat room between Bob and herself) <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpRequest xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-sidebarByVal-request-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977878@example.com</confObjID> <operation>create</operation> <ccmp:sidebarByValRequest> <sidebarByValInfo entity="xcon:AUTO_GENERATE_1@example.com">
<info:conference-description>
<info:display-text>
private textual sidebar alice - bob
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="AUTO_GENERATE_2">
<info:display-text>
sidebar text
</info:display-text>
<info:type>text</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-out"
uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. sidebarByValResponse/create message (sidebar returned)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:sidebarByValResponse>
<sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description>
<info:display-text>
private textual sidebar alice - bob
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>recvonly</info:status>
</info:entry>
<info:entry label="789">
<info:display-text>
sidebar text
</info:display-text>
<info:type>text</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
<xcon:sidebar-parent>
xcon:8977878@example.com
</xcon:sidebar-parent>
</info:conference-description>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-out"
uri="xcon-userid:Alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:Bob@example.com"/>
</xcon:allowed-users-list>
</info:users> </sidebarByValInfo> </ccmp:sidebarByValResponse> </ccmpResponse> </ccmp:ccmpResponse> Figure 23: Sidebar for Private Messages Scenario7.4. Observing and Coaching
"Observing and Coaching" is one of the most interesting sidebar- related scenarios. In fact, it highlights two different interactions that have to be properly coordinated. An example of observing and coaching is shown in Figure 25. In this example, call center agent Bob is involved in a conference with customer Carol. Since Bob is a new agent and Alice sees that he has been on the call with Carol for longer than normal, she decides to observe the call and coach Bob as necessary. Of course, the conferencing system must make sure that the customer Carol is not aware of the presence of the coach Alice. This makes the use of a sidebar necessary for the success of the scenario. Consider the following as the conference document associated with the video conference involving Bob (the call agent) and Carol (the customer) (Figure 24): <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <info:conference-info xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" entity="xcon:8978383@example.com"> <info:conference-description> <info:display-text> CUSTOMER SERVICE conference </info:display-text> <info:conf-uris> <info:entry> <info:uri>sip:8978383@example.com</info:uri> <info:display-text>conference sip uri</info:display-text> </info:entry> </info:conf-uris> <info:available-media> <info:entry label="123"> <info:display-text>service audio</info:display-text> <info:type>audio</info:type> <info:status>sendrecv</info:status>
</info:entry> <info:entry label="456"> <info:display-text>service video</info:display-text> <info:type>video</info:type> <info:status>sendrecv</info:status> <xcon:controls> <xcon:video-layout>single-view</xcon:video-layout> </xcon:controls> </info:entry> </info:available-media> </info:conference-description> <info:conference-state> <info:active>true</info:active> </info:conference-state> <info:users> <info:user entity="xcon-userid:bob@example.com"> <info:display-text>Bob - call agent</info:display-text> <info:endpoint entity="sip:bob@example.com"> <info:media id="1"> <info:label>123</info:label> <info:status>sendrecv</info:status> </info:media> <info:media id="2"> <info:label>456</info:label> <info:status>sendrecv</info:status> </info:media> </info:endpoint> </info:user> <info:user entity="xcon-userid:carol@example.com"> <info:display-text>Carol - customer</info:display-text> <info:endpoint entity="sip:carol@example.com"> <info:media id="1"> <info:label>123</info:label> <info:status>sendrecv</info:status> </info:media> <info:media id="2"> <info:label>456</info:label> <info:status>sendrecv</info:status> </info:media> </info:endpoint> </info:user> </info:users> </info:conference-info> Figure 24: A Call-Center Conference Object Example
Alice Bob ConfS | | | |(1) sidebarByRefRequest(confUserID, | | confObjID, create) | |--------------------------------------------->| | | | | | (a) Create +---| | | sidebar-by-ref | | | | (new conf obj | | | | cloned from +-->| | | confObjID) | Sidebar now has | | | id confObjID* |(2) sidebarByRefResponse(confUserID, | (parent mapping | confObjID*,create,200,success, | conf<->sidebar) | version,sidebarByRefInfo) | |<---------------------------------------------| | | | |(3) sidebarByRefRequest(confUserID, | | confObjID*,update,sidebarByRefInfo) | |--------------------------------------------->| | | | | | (b) Update +---| | | sidebar-by-val | | | | (media, users | | | | policy, etc.) +-->| | | | Sidebar is modified: | | | unilateral sidebar | | | audio, Carol excluded | | | from the sidebar |(4) sidebarByRefResponse(confUserID, | | confObjID*, update, | | 200, success, version) | |<---------------------------------------------| | | | | | Notify (Bob | | | he's been added to | | | sidebar users) | | |<----------------------| | | | ' ' ' ' ' ' ' ' ' Figure 25: Supervisor Creating a Sidebar for Observing/Coaching
1. Upon receipt of the sidbarByRefRequest/create message from Alice
to create a new sidebar conference from the <confObjID> received
in the request, the conference server uses the received active
conference to clone a conference reservation for the sidebar.
The conference server also allocates a new XCON-URI to be used
for any subsequent protocol requests directed to the new sidebar.
The conference server maintains the mapping between this sidebar
conference ID and the one associated with the main conference
instance. The conference server sends a sidebarByRefResponse
message with the new XCON-URI in the <confObjID> field and other
relevant information in the <sidebarByRefInfo>.
2. Upon receipt of the sidebarByRefResponse message, Alice
manipulates the data received in the <sidebarByRefInfo> in the
response. Alice wants only Bob to be involved in the sidebar;
thus, she updates the <allowed-users-list> to include only Bob
and herself. Alice also wants the audio to be received by
herself and Bob from the original conference, but wants any
outgoing audio from herself to be restricted to the participants
in the sidebar, whereas Bob's outgoing audio should go to the
main conference, so that both Alice and the customer Carol hear
the same audio from Bob. Alice sends a sidebarByRefRequest
message with an "update" <operation> including the updated
sidebar information in the <sidebarByRefInfo> element.
3. Upon receipt of the sidebarByRefRequest/update message, the
conference server ensures that Alice has the appropriate
authority based on the policies associated with that specific
conference object to perform the operation. In order to request
the insertion of a further media stream in the sidebar (i.e., in
this example an audio stream from Alice to Bob), the requester
has to provide a new <entry> element in the <available-media>
field of the <sidebarByRefInfo>. The mandatory 'label' attribute
of that new <entry> is filled with a dummy value
"AUTO_GENERATE_1", but it will contain the real server-generated
media stream identifier when the media stream is effectively
allocated on the server side. Similarly, the mandatory 'id'
attribute in the <media> element referring to the new sidebar
audio stream under both Alice's and Bob's <endpoint> contains a
wildcard value, respectively, "AUTO_GENERATE_2" and
"AUTO_GENERATE_3": those values will be replaced with the
appropriated server-generated identifiers upon the creation of
the referred media stream. We are assuming the conference server
is able to recognize those dummy values as placeholders.
4. After validating the data, the conference server sends a
sidebarByRefResponse message. Based upon the contact information
provided for Bob by Alice, the call signaling to add Bob to the
sidebar with the appropriate media characteristics is instigated
through the focus. Bob is notified of his addition to the
sidebar via the conference notification service; thus, he is
aware that Alice, the supervisor, is available for coaching him
through this call.
1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8978383@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. sidebarByRefResponse/create message (sidebar created)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>1</version>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971313@example.com">
<info:conference-description>
<info:display-text>
SIDEBAR CONFERENCE registered by alice
</info:display-text>
<info:available-media>
<info:entry label="123">
<info:display-text>
main conference audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
<xcon:sidebar-parent>
xcon:8971313@example.com
</xcon:sidebar-parent>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:alice@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:bob@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:carol@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
3. sidebarByRefRequest/update message (Alice introduces unilateral
sidebar audio and excludes Carol from the sidebar)
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByRefRequest>
<sidebarByRefInfo entity="xcon:8971313@example.com">
<info:conference-description>
<info:display-text>
Coaching sidebar Alice and Bob
</info:display-text>
<info:available-media>
<info:entry label="AUTO_GENERATE_1">
<info:display-text>
Alice-to-Bob audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
</info:available-media>
</info:conference-description>
<info:conference-state>
<info:active>false</info:active>
</info:conference-state>
<info:users>
<info:user entity="xcon-userid:alice@example.com">
<info:endpoint entity="sip:alice@example.com">
<info:media id="AUTO_GENERATE_2">
<info:label>AUTO_GENERATE_1</info:label>
<info:status>sendonly</info:status>
</info:media>
</info:endpoint>
</info:user>
<info:user entity="xcon-userid:bob@example.com">
<info:endpoint entity="sip:bob@example.com">
<info:media id="AUTO_GENERATE_3">
<info:label>AUTO_GENERATE_1</info:label>
<info:status>recvonly</info:status>
</info:media>
</info:endpoint>
</info:user>
<xcon:allowed-users-list>
<xcon:target method="dial-in"
uri="xcon-userid:alice@example.com"/>
<xcon:target method="dial-out"
uri="xcon-userid:bob@example.com"/>
</xcon:allowed-users-list>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
4. sidebarByRefRequest/update message (updates accepted) <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-sidebarByRef-response-message-type"> <confUserID>xcon-userid:alice@example.com</confUserID> <confObjID>xcon:8971313@example.com</confObjID> <operation>update</operation> <response-code>200</response-code> <response-string>success</response-string> <version>2</version> <ccmp:sidebarByRefResponse/> </ccmpResponse> </ccmp:ccmpResponse> Figure 26: Coaching and Observing Messaging Details8. Removing Participants and Deleting Conferences
The following scenarios detail the basic operations associated with removing participants from conferences and entirely deleting conferences. The examples assume that a conference has already been correctly established, with media, if applicable, per one of the examples in Section 5.8.1. Removing a Party
Figure 27 provides an example of a client, Alice, removing another participant, Bob, from a conference. This example assumes an established conference with Alice, Bob, Claire, and Duck. In this example, Alice wants to remove Bob from the conference so that the group can continue in the same conference without Bob's participation.
Alice Bob Claire ConfS | | | | |(1) userRequest(confUserID,| | | confObjID, delete,| | | userInfo) | | |-------------------------------------->| | | | | | | | (a) Focus | | | | tears down| | | | signaling | | | | to Bob | | |<----------------------| | | | | | (b)Deletes+---| | | | Bob | | | | | as a | | | | | user +-->| | | | in | | | | confObj | | | | | |(2) userResponse(confUserID,confObjID, | | delete,200,success,version) | |<--------------------------------------| | | | | | | | | | | | (c) Notify| | | | ("Bob just| | | | left") | | | |<----------| | | | | ' ' ' ' ' ' ' ' ' ' ' ' Figure 27: Client Manipulation of Conference - Remove a Party 1. Alice sends a userRequest message with a "delete" <operation>. The conference server ensures that Alice has the appropriate authority based on the policies associated with that specific conference object to perform the operation. 2. Based upon the contact and media information in the conference object for Bob in the <userInfo> element, the conferencing system starts the process to remove Bob (e.g., the call signaling to remove Bob from the conference is instigated through the focus). The conference server updates the data in the conference object, thus, removing Bob from the <users> list. After updating the data, the conference server sends a userResponse message to
Alice. Depending upon the policies, other participants (e.g.,
Claire) may be notified of the removal of Bob from the conference
via the conference notification service.
1. userRequest/delete message (Alice deletes Bob)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com"/>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse/delete message (Bob has been deleted)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>17</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 28: Removing a Participant Messaging Details
8.2. Deleting a Conference
In this section, an example of a successful conference deletion is provided (Figure 29). Alice ConfS | | |(1)confRequest(confUserID, | | confObjID, delete) | |------------------------------>| | (a)Delete +---| | Conf | | | Object | | | +-->| | |--+ (b) MS | | | removes related | | | mixer instances and | |<-+ their participants | | (SIP signaling as well) | | |(2)confResponse(confUserID, | | confObjID,delete,200, | | success) | | | |<------------------------------| | | ' ' Figure 29: Deleting a Conference 1. The conferencing system client Alice sends a confRequest message with a "delete" operation to be performed on the conference identified by the XCON-URI carried in the <confObjID> parameter. The conference server, on the basis of the <confUserID> included in the receipt request, ensures that Alice has the appropriate authority to fulfill the operation. 2. After validating Alice's rights, the conference server instigates the process to delete the conference object, disconnecting participants and removing associated resources such as mixer instances. Then, the conference server returns a confResponse message to Alice with "200" as <response-code> and the deleted conference XCON-URI in the <confObjID> field.
1. confRequest/delete message (Alice deletes a conference) <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-conf-request-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>delete</operation> <ccmp:confRequest/> </ccmpRequest> </ccmp:ccmpRequest> 2. confResponse/delete message ("200", "success") <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-conf-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>delete</operation> <response-code>200</response-code> <response-string>success</response-string> <ccmp:confResponse/> </ccmpResponse> </ccmp:ccmpResponse> Figure 30: Deleting a Conference Messaging Details9. Security Considerations
The security considerations applicable to the implementation of these call flows are documented in the XCON framework, with additional security considerations documented in the CCMP document. Statements with regard to the necessary security are discussed in particular flows; however, this is for informational purposes only. The implementer is encouraged to carefully consider the security requirements in the normative documents.
10. Acknowledgements
The detailed content for this document is derived from the prototype work of Lorenzo Miniero, Simon Pietro Romano, Tobia Castaldi, and their colleagues at the University of Napoli.11. References
11.1. Normative References
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008. [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012. [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012. [RFC6503] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, March 2012. [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.11.2. Informative References
[CALL-FLOWS] Amirante, A., Castaldi, T., Miniero, L., and S. Romano, "Media Control Channel Framework (CFW) Call Flow Examples", Work in Progress, July 2011. [RFC3261] 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. [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006. [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006. [RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009. [RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer Control Package for the Media Control Channel Framework", RFC 6505, March 2012.
Authors' Addresses
Mary Barnes Polycom TX USA EMail: mary.ietf.barnes@gmail.com Lorenzo Miniero Meetecho Via Carlo Poerio 89/a Napoli 80121 Italy EMail: lorenzo@meetecho.com Roberta Presta University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: roberta.presta@unina.it Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: spromano@unina.it