RFC 6504
Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples
Pages: 78
Informational
Informational
Part 3 of 4 – Pages 31 to 60
6. Conference Users Scenarios and Examples
Section 5 showed examples describing the several different ways a conference might be created using CCMP. This section focuses on user-related scenarios, i.e., typical scenarios that may occur during
the lifetime of a conference, like adding new users and handling their media. The following scenarios are based on those documented in the XCON framework. The examples assume that a conference has already been correctly established, with media, if applicable, per one of the examples in Section 5.6.1. Adding a Party
In this example, Alice wants to add Bob to an established conference. In the following example we assume Bob is a new user of the system, which means Alice also needs to provide some details about him. In fact, the case of Bob already present as a user in the conferencing system is much easier to address, and will be discussed later. Alice Bob CMCC1 CMCC2 CMCCx ConfS | | | | |(1) userRequest(confUserID,| | | confObjID, create, | | | userInfo) | | | |-------------------------------------->| | | | | | | (a) Create +---| | | | Bob | | | | | as a | | | | | user +-->| | | | | |(2) userResponse(confUserID, confObjID | | create, 200, success, userInfo) | |<--------------------------------------| | | | | | | | (b) Focus | | | | sets up | | | | signaling | | | | to Bob | | |<----------------------| | | | | | | | (c) Notify| | | | ("Bob just| | | | joined") | | | |<----------| | | | | ' ' ' ' ' ' ' ' ' ' ' ' Figure 11: Client Manipulation of Conference - Add a Party
1. Alice sends a userRequest message with an operation of "create"
to add Bob to the specific conference as identified by the XCON-
URI in the <confObjID>. The "create" <operation> also makes sure
that Bob is created as a user in the whole conferencing system.
This is done by adding in the request a <userInfo> element
describing Bob as a user. This is needed in order to let the
conferencing system be aware of Bob's characteristics. In case
Bob was already a registered user, Alice would just have
referenced him through his XCON-USERID in the 'entity' attribute
of the <userInfo> field, without providing additional data. In
fact, that data (including, for instance, Bob's SIP-URI to be
used subsequently for dial-out) would be obtained by referencing
the extant registration. The conference server ensures that
Alice has the appropriate authority based on the policies
associated with that specific conference object to perform the
operation. As mentioned before, a new XCON-USERID is created for
Bob, and the <userInfo> is used to update the conference object
accordingly. As already seen in Section 5.3, a placeholder
wildcard ("xcon-userid:AUTO_GENERATE_1@example.com" in the CCMP
messages below) is used for the 'entity' attribute of the
<userInfo> element, to be replaced by the actual XCON-USERID
later;
2. Bob is successfully added to the conference object, and an XCON-
USERID is allocated for him ("xcon-userid:Bob@example.com"); this
identifier is reported in the response as the value of the
'entity' attribute of the returned <userInfo>;
3. In the presented example, the call signaling to add Bob to the
conference is instigated through the focus as well. As noted
previously, this is implementation specific. In fact, a
conferencing system may accomplish different actions after the
user creation, just as it may do nothing at all. Among the
possible actions, for instance, Bob may be added as a <target>
element to the <allowed-users-list> element, whose joining
'method' may be either "dial-in" or "dial-out". Besides, out-of-
band notification mechanisms may be involved as well, e.g., to
notify Bob via mail of the new conference, including details as
the date, password, expected participants, and so on (see
Section 4.3).
Once Bob has been successfully added to the specified conference,
per updates to the state, and depending upon the policies, other
participants (including Bob himself) may be notified of the
addition of Bob to the conference via the conference notification
service in use.
1. userRequest/create message (Alice adds 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:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<info:display-text>Bob</info:display-text>
<info:associated-aors>
<info:entry>
<info:uri>mailto:bob.depippis@example.com</info:uri>
<info:display-text>Bob's email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:bob83@example.com">
<info:display-text>Bob's laptop</info:display-text>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse/create message (a new XCON-USERID is
created for Bob and he is added to the conference)
<?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:8977878@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>10</version>
<ccmp:userResponse>
<userInfo entity="xcon-userid:Bob@example.com">
<info:display-text>Bob</info:display-text>
<info:associated-aors>
<info:entry>
<info:uri>mailto:bob.depippis@example.com</info:uri> <info:display-text>Bob's email</info:display-text> </info:entry> </info:associated-aors> <info:endpoint entity="sip:bob83@example.com"> <info:display-text>Bob's laptop</info:display-text> </info:endpoint> </userInfo> </ccmp:userResponse> </ccmpResponse> </ccmp:ccmpResponse> Figure 12: Add Party Message Details6.2. Muting a Party
This section provides an example of the muting of a party in an active conference. We assume that the user to mute has already been added to the conference. The document only addresses muting and not unmuting, since the latter would involve an almost identical CCMP message flow anyway. However, if any external floor control is involved, whether a particular conferencing client can actually mute/ unmute itself must be considered by the conferencing system. Please notice that interaction between CCMP and floor control should be carefully considered. In fact, handling CCMP- and BFCP- based media control has to be considered as multiple layers: that is, a participant may have the BFCP floor granted, but be muted by means of CCMP. If so, he would still be muted in the conference, and would only be unmuted if both the protocols allowed for this. Figure 13 provides an example of one client, Alice, impacting the media state of another client, Bob. This example assumes an established conference. In this example, Alice, who is the moderator of the conference, wants to mute Bob on a medium-sized multi-party conference, as his device is not muted (and he's obviously not listening to the call) and background noise in his office environment is disruptive to the conference. BFCP floor control is assumed not to be involved. Muting can be accomplished using the <mute> control element associated with the target user's audio, in which case the conference server must update the settings associated with the user's media streams. Muting/unmuting can also be accomplished by directly modifying the settings related to the target user's media streams, which is the approach shown in this example. Specifically, Bob's <userInfo> is updated by modifying the <endpoint> element in the
<media> part related to audio information, identified by the 'id' attribute. The modification consists in setting the audio <status> to "recvonly", in case of muting. Alice Bob CMCC1 CMCC2 CMCCx ConfS MS | | | | | |(1) userRequest(subject, | | | | confUserID,confObjID, | | | | update,userInfo) | | | | | | | | |--------------------------------------->| | | | | | Mute Bob | | | | |----------------->| | | | | 200 OK | | | | |<-----------------| | | | | | | |<====== XXX Bob excluded from mix XXX ====>| | | | | | | | (a) Update +---| | | | Bob in | | | | | data model | | | | | (muted) +-->| | | | | | | | (2)userResponse(confUserID,confObjID, | | | update,200,success,version) | | |<---------------------------------------| | | | | | | | | | (b) Notify | | | | | ("Bob is | | | | | muted") | | | | |<-----------| | | | | | | ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' Figure 13: Client Manipulation of Conference - Mute a Party 1. Alice sends a userRequest message with an "update" <operation> and the <userInfo> with the <status> field in the <media> element for Bob's <endpoint> set to "revconly". In order to authenticate herself, Alice provides in the <subject> request parameter her registration credentials (i.e., username and password). The <subject> parameter is an optional one: its use can be systematic whenever the conference server envisages to authenticate each
requester. In such cases, if the client does not provide the
required authentication information, the conferencing server
answers with a CCMP "authenticationRequired" <response-code>,
indicating that the request cannot be processed without including
the proper <subject> parameter. The conference server ensures
that Alice has the appropriate authority based on the policies
associated with that specific conference object to perform the
operation. It recognizes that Alice is allowed to request the
specified modification, since she is moderator of the target
conference, and updates the <userInfo> in the conference object
reflecting that Bob's media is not to be mixed with the
conference media. If the conference server relies on a remote
media server for its multimedia functionality, it subsequently
changes Bob's media profile accordingly by means of the related
protocol interaction with the MS. An example describing a
possible way of dealing with such a situation using the media
server control architecture [RFC5567] is described in Figure 31,
"Simple Bridging: Framework Transactions (2)", in [CALL-FLOWS].
2. A userResponse message with a "200" <response-code> ("success")
is then sent to Alice. Depending upon the policies, the
conference server may notify other participants (including Bob)
of this update via any conference notification service that may
be in use.
1. userRequest/update message (Alice mutes 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">
<subject>
<username>Alice83</username>
<conference-password>13011983</conference-password>
</subject>
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>update</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com">
<info:endpoint entity="sip:bob83@example.com">
<info:media id="1">
<info:label>123</info:label>
<info:status>recvonly</info:status>
</info:media>
</info:endpoint>
</userInfo> </ccmp:userRequest> </ccmpRequest> </ccmp:ccmpRequest> 2. userResponse/update message (Bob has been muted) <?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:8977878@example.com</confObjID> <operation>update</operation> <response-code>200</response-code> <response-string>success</response-string> <version>7</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse> Figure 14: Mute Message Details6.3. Conference Announcements and Recordings
This section deals with features that are typically required in a conferencing system, such as public announcements (e.g., to notify vocally that a new user joined a conference) and name recording. While this is not strictly CCMP-related (the CCMP signaling is actually the same as the one seen in Section 6.1), it is an interesting scenario to address to see how several components of an XCON-compliant architecture interact with each other to make it happen. In this example, as shown in Figure 15, Alice is joining Bob's conference that requires that she first enter a passcode. After successfully entering the passcode, an announcement prompts Alice to speak her name so it can be recorded. When Alice is added to the active conference, the recording is played back to all the existing participants. A very similar example is presented in Figure 33 of [CALL-FLOWS].
CMCC Alice ConfS MS
| | |
|(1)userRequest(confObjID, | |
| create,userInfo) | |
|--------------------------->| |
| |--+ Alice is |
| | | new in the |
| |<-+ system (create |
| | confUserID) |
| ConfS handles +--| |
| SIP signaling | | |
| (Alice<->ConfS<->MS) +->| |
| | |
| |--+ A password is |
| | | required for |
| |<-+ that conference |
| | |
| | Request IVR menu (PIN) |
| |--------------------------->|
| | |
|<========= MS gets PIN from Alice through DTMF =========>|
| | |
| | Provided PIN is... |
| |<---------------------------|
| Check +--| |
| PIN | | |
| +->| |
| |--+ Alice must |
| | | record her |
| |<-+ name |
| | |
| | Request name recording |
| |--------------------------->|
| | |
|<========= MS records Alice's audio RTP (name) =========>|
| | |
| | Audio recording |
| |<---------------------------|
| Complete +--| |
| creation | | |
| of Alice +->| |
| | | | | | | (2)userResponse(confUserID,| | | confObjID,create,200,| | | success,version) | | |<---------------------------| | | | | ' ' ' Figure 15: Recording and Announcements 1. Upon receipt of the userRequest message from Alice to be added to Bob's conference, the conference server determines that a password is required for this specific conference. Thus, an announcement asking Alice to enter the password is sent back. This may be achieved by means of typical IVR functionality. Once Alice enters the password, it is validated against the policies associated with Bob's active conference. The conference server then connects to a server that prompts and records Alice's name. The conference server must also determine whether Alice is already a user of this conferencing system or whether she is a new user. In this case, Alice is a new user for this conferencing system, so a new XCON-USERID is created for Alice. Based upon the contact information provided by Alice, the call signaling to add Alice to the conference is instigated through the focus. 2. The conference server sends Alice a userResponse message that includes in the <confUserID> the XCON-USERID assigned by the conferencing system to her. This would allow Alice to later perform operations on the conference (if she were to have the appropriate policies), including registering for event notifications associated with the conference. Once the call signaling indicates that Alice has been successfully added to the specific conference, per updates to the state, and depending upon the policies, other participants (e.g., Bob) are notified of the addition of Alice to the conference via the conference notification service and an announcement is provided to all the participants indicating that Alice has joined the conference. 1. userRequest/create message (a new conferencing system client, Alice, enters Bob's 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-user-request-message-type"> <confObjID>xcon:bobConf@example.com</confObjID> <operation>create</operation> <ccmp:userRequest> <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com"> <info:associated-aors> <info:entry> <info:uri> mailto:Alice83@example.com </info:uri> <info:display-text>email</info:display-text> </info:entry> </info:associated-aors> <info:endpoint entity="sip:alice_789@example.com"/> </userInfo> </ccmp:userRequest> </ccmpRequest> </ccmp:ccmpRequest> 2. userResponse/create message (Alice provided with a new XCON-USERID and added to the conference) <?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:bobConf@example.com</confObjID> <operation>create</operation> <response-code>200</response-code> <response-string>success</response-string> <version>5</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse> Figure 16: Announcement Messaging Details6.4. Monitoring for DTMF
Conferencing systems also often need the capability to monitor for dual-tone multi-frequency (DTMF) from each individual participant. This would typically be used to enter the identifier and/or access code for joining a specific conference. This feature is also often
exploited to achieve interaction between participants and the conferencing system for non-XCON-aware user agents (e.g., using DTMF tones to get muted/unmuted). An example of DTMF monitoring, within the context of the framework elements, is shown in Figure 15. The media control architecture and protocols [RFC5567] can be used by the conference server for all the DTMF interactions. Examples for DTMF interception in conference instances are presented in [CALL-FLOWS].6.5. Entering a Password-Protected Conference
Some conferences may require a password to be provided by a user who wants to manipulate the conference objects (e.g., join, update, delete) via CCMP. In this case, a password would be included in the <conference-password> element in the appropriate <conference-uris> entry of the conference data model. Such password must be then included in the <conference-password> field in the CCMP request addressed to that conference. In the following example, Alice, a conferencing system client, attempts to join a password-protected conference. 1. Alice sends a userRequest message with a "create" <operation> to add herself in the conference with XCON-URI "xcon:8977777@example.com" (written in the <confObjID> parameter). Alice provides her XCON-USERID via the <confUserID> field of the userRequest message and leaves out the <userInfo> one (first-party join). In this first attempt, she doesn't insert any password parameter. 2. Upon receipt the userRequest/create message, the conference server detects that the indicated conference is not joinable without providing the appropriate passcode. A userResponse message with a "423" <response-code> ("conference password required") is returned to Alice to indicate that her join has been refused and that she has to resend her request including the appropriate conference password in order to participate. 3. After getting the passcode through out-of-band mechanisms, Alice provides it in the proper <conference-password> request field of a new userRequest/create message and sends the updated request back to the server. 4. The conference server checks the provided password and then adds Alice to the protected conference. After that, a userResponse message with a "200" <response-code> ("success") is sent to Alice.
1. userRequest/create message (Alice tries to enter the conference
without providing the password)
<?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>create</operation>
<ccmp:userRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse/create message ("423", "conference password required")
<?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>create</operation>
<response-code>423</response-code>
<response-string>conference password required</response-string>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
3. userRequest/create message (Alice provides the password)
<?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>create</operation>
<conference-password>8601</conference-password>
<ccmp:userRequest/> </ccmpRequest> </ccmp:ccmpRequest> 4. userResponse/create message (Alice has been added to the conference) <?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>create</operation> <response-code>200</response-code> <response-string>success</response-string> <version>10</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse> Figure 17: Password-Protected Conference Join Messages Details7. Sidebars Scenarios and Examples
While creating conferences and manipulating users and their media are sufficient for many scenarios, there may be cases when more complex management is needed. In fact, a feature typically required in conferencing systems is the ability to create sidebars. A sidebar is basically a child conference that usually includes a subset of the participants of the parent conference and a subset of its media as well. Sidebars are typically required whenever some of the participants in a conference want a private discussion, without interfering with the main conference. This section deals with some typical scenarios using a sidebar, like whispering, private messaging, and coaching scenarios. The first subsections present some examples of how a generic sidebar can be created, configured, and managed.
7.1. Internal Sidebar
Figure 18 provides an example of one client, Alice, involved in an active conference with Bob and Carol. Alice wants to create a sidebar to have a side discussion with Bob while still viewing the video associated with the main conference. Alternatively, the audio from the main conference could be maintained at a reduced volume. Alice initiates the sidebar by sending a request to the ConfS to create a conference reservation based upon the active conference object. Alice and Bob would remain on the roster of the main conference, such that other participants could be aware of their participation in the main conference, while an internal-sidebar conference is occurring. Besides, Bob decides that he is not interested in still receiving the conference audio in background (not even at a lower volume as Alice configured) and so modifies the sidebar in order to make that stream inactive for him. Alice Bob ConfS | | | |(1) sidebarByValRequest(confUserID, | | confObjID,create) | |--------------------------------------------->| | | | | | (a) Create +---| | | sidebar-by-val | | | | (new conf obj | | | | cloned from +-->| | | confObjID) | Sidebar now has | | | id confObjID* |(2) sidebarByValResponse(confUserID, | (parent mapping | (confObjID*,create,200,success, | conf<->sidebar) | version,sidebarByValInfo) | |<---------------------------------------------| | | | |(3) sidebarByValRequest | | (confUserID, confObjID*, | | update,sidebarByValInfo) | |--------------------------------------------->| | | |
| | (b) Update +---| | | sidebar-by-val | | | | (media, users | | | | etc.) +-->| | | | Sidebar is | | | modified |(4) sidebarByValResponse(confUserID, | | confObjID*, update, | | 200, success, version) | |<---------------------------------------------| | | | | |(5) userRequest | | | (confUserID', | | | confObjID*, | | | update,userInfo)| | |---------------------->| | | | | | (c) Update +---| | | user settings | | | | (Bob's media) | | | | +-->| | | | Sidebar is modified | | | (original audio | | | inactive for Bob) | |(6) userResponse | | | (confUserID', | | | confObjID*, | | | update, 200, | | | success,version) | | |<----------------------| | | | ' ' ' ' ' ' ' ' ' Figure 18: Client Creation of a Sidebar Conference 1. Upon receipt of CCMP sidebarByValRequest message to create a new sidebar based upon the conference whose XCON-URI is in the <confObjID> received in the request, the conference server uses such XCON-URI to clone a conference reservation for the sidebar. The sidebar reservation is NOT independent of the active main conference (i.e., parent). The conference server also allocates a new XCON-URI ("confObjID*" in Figure 18) for that sidebar to be used for any subsequent protocol requests from any of the members of the conference. The new XCON-URI is returned in the response message <confObjID> parameter.
2. The relationship information is provided in the
sidebarByValResponse message, specifically in the <sidebar-
parent> element. A dump of the complete representation of the
main/parent conference is provided below as well to show how the
cloning process for the creation of the sidebar could take place.
3. Upon receipt of the sidebarByValResponse message to reserve the
conference, Alice can now create an active conference using that
reservation or create additional reservations based upon the
existing reservations. In this example, Alice wants only Bob to
be involved in the sidebar; thus, she manipulates the membership
so that only the two of them appear in the <allowed-users-list>
section. Alice also wants both audio and video from the original
conference to be available in the sidebar. For what concerns the
media belonging to the sidebar itself, Alice wants the audio to
be restricted to the participants in the sidebar (that is, Bob
and herself). Additionally, Alice manipulates the media values
to receive the audio from the main conference at a reduced
volume, so that the communication between her and Bob isn't
affected. Alice sends a sidebarByValRequest message with an
operation of "update" along with the <sidebarByValInfo>
containing the aforementioned sidebar modifications.
4. Upon receipt of the sidebarByValRequest message to update the
sidebar reservation, the conference server ensures that Alice has
the appropriate authority based on the policies associated with
that specific conference object to perform the operation. The
conference server must also validate the updated information in
the reservation, ensuring that a member like Bob is already a
user of this conference server. Once the data for the conference
identified by the <confObjID> is updated, the conference server
sends a sidebarByValResponse message to Alice. Depending upon
the policies, the initiator of the request (i.e., Alice) and the
participants in the sidebar (i.e., Bob) may be notified of his
addition to the sidebar via the conference notification service.
5. At this point, Bob sends a userRequest message to the conference
server with an operation of "update" to completely disable the
background audio from the parent conference, since it prevents
him from understanding what Alice says in the sidebar.
6. Notice that Bob's request only changes the media perspective for
Bob. Alice keeps on receiving both the audio from Bob and the
background from the parent conference. This request may be
relayed by the conference server to the media server handling the
mixing, if present. Upon completion of the change, the
conference server sends a userResponse message to Bob. Depending
upon the policies, the initiator of the request (i.e., Bob) and
the participants in the sidebar (i.e., Alice) may be notified of
this change via the conference notification service.
The following conference object represents the conference in which
the sidebar is to be created. It will be used by the conference
server to create the new conference object associated with the
sidebar.
<?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:8977878@example.com">
<info:conference-description>
<info:display-text>MAIN CONFERENCE</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>sip:8977878@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>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>
<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:Alice@example.com">
<info:display-text>Alice</info:display-text>
<info:endpoint entity="sip:Alice@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:Bob@example.com"> <info:display-text>Bob</info:display-text> <info:endpoint entity="sip:bob83@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</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 19: Conference with Alice, Bob, and Carol The sidebar creation happens through a cloning of the parent conference. Once the sidebar is created, an update request makes sure that the sidebar is customized as needed. The following protocol dump makes the process clearer.
1. sidebarByValRequest/create message (Alice creates an
internal 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-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<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>
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>
</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>
<xcon:sidebar-parent>
xcon:8977878@example.com
</xcon:sidebar-parent>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
3. sidebarByValRequest/update message (Alice updates the
created sidebar)
<?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:8974545@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description>
<info:display-text>
private 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>
<xcon:controls>
<xcon:gain>-60</xcon:gain>
</xcon:controls>
</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_1">
<info:display-text>
sidebar audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="AUTO_GENERATE_2">
<info:display-text>
sidebar video
</info:display-text>
<info:type>video</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>
4. sidebarByValResponse/update message (sidebar's
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-sidebarByVal-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByValResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
5. userRequest/update message (Bob updates his media)
<?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-user-request-message-type">
<confUserID>xcon-userid:Bob@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com">
<info:endpoint entity="sip:bob83@example.com">
<info:media id="1">
<info:display-text>
main conference audio
</info:display-text>
<info:label>123</info:label>
<info:status>inactive</info:status>
</info:media>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
6. userResponse/update message (Bob's preferences are set) <?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:Bob@example.com</confUserID> <confObjID>xcon:8974545@example.com</confObjID> <operation>update</operation> <response-code>200</response-code> <response-string>success</response-string> <version>3</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse> Figure 20: Internal Sidebar Messaging Details7.2. External Sidebar
Figure 21 provides an example of a different approach towards sidebars. In this scenario, one client, Alice, is involved in an active conference with Bob, Carol, David, and Ethel. Alice gets an important text message via a whisper from Bob that a critical customer needs to talk to Alice, Bob, and Ethel. Alice creates a sidebar to have a side discussion with the customer Fred including the participants in the current conference with the exception of Carol and David, who remain in the active conference. The difference from the previous scenario is that Fred is not part of the parent conference: this means that different policies might be involved, considering that Fred may access information coming from the parent conference, in case the sidebar was configured accordingly. For this reason, in this scenario, we assume that Alice disables all the media from the original (parent) conference within the sidebar. This means that, while in the previous example Alice and Bob still heard the audio from the main conference in background, this time no background is made available. Alice initiates the sidebar by sending a request to the conference server to create a conference reservation based upon the active conference object. Alice, Bob and Ethel would remain on the roster of the main conference in a hold state. Whether or not the hold state of these participants is visible to other participants depends upon the individual and local policy. However, providing the hold state allows the participants in the main conference to see that others in the conference are busy. Note, that a separate conference could have been created by Alice to allow Bob and Ethel to talk to Fred. However, creating a sidebar has somewhat of an advantage by
allowing the conference to be created using some of the same settings
(e.g., role, floor control, etc.) that Bob and Ethel had in the main
conference and it would allow for updates such that the media could
be updated, for example, to provide audio from the main conference.
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) Create +---|
| | new user for | |
| | Fred | |
| | +-->|
| | |
| | (c) Update +---|
| | sidebar-by-ref | |
| | (media, users | |
| | policy, etc.) +-->|
| | | Sidebar is modified:
| | | media from the
| | | parent conference is
| | | not available to
|(4) sidebarByRefResponse(confUserID, | anyone
| confObjID*, update, |
| 200, success, version) |
|<---------------------------------------------|
| | |
| | Notify (Fred | | | added to | | | sidebar users) | | |<----------------------| | | | ' ' ' ' ' ' ' ' ' Figure 21: Client Creation of an External Sidebar 1. Upon receipt of the sidebarByRefRequest message to create a new sidebar conference, based upon the active conference specified by <confObjID> in the request, the conference server uses that active conference to clone a conference reservation for the sidebar. The sidebar reservation is NOT independent of the active conference (i.e., parent). The conference server, as before, allocates a new XCON-URI ("confObjID*" in Figure 21) to be used for any subsequent protocol requests toward the sidebar reservation. The mapping between the sidebar XCON-URI and the one associated with the main conference is maintained by the conference server and it is gathered from the <sidebar-parent> element in the sidebar conference object. 2. Upon receipt of the sidebarByRefResponse message, which acknowledges the successful creation of the sidebar object, Alice decides that only Bob and Ethel, along with the new participant Fred are to be involved in the sidebar. Thus, she manipulates the membership accordingly. Alice also sets the media in the <conference-info> such that the participants in the sidebar don't receive any media from the main conference. All these settings are provided to the conferencing server by means of a new sidebarByRefRequest message, with an "update" <operation>. 3. Alice sends the aforementioned sidebarByRefRequest message to update the information in the reservation and to create an active conference. 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. The conference server also validates the updated information in the reservation. Since Fred is a new user for this conferencing system, a conference user identifier (XCON-USERID) is created for Fred. Specifically, Fred is added to the conference by only providing his SIP URI. Based upon the contact information provided for Fred by Alice, the call signaling to add Fred to the conference may be instigated through the focus (e.g., if Fred had
a "dial-out" value for the 'method' attribute in his <target>
field under <allowed-users-list>) at the actual activation of the
sidebar.
4. The conference server sends a sidebarByRefResponse message and,
depending upon the policies, the initiator of the request (i.e.,
Alice) and the participants in the sidebar (i.e., Bob and Ethel)
may be notified of his addition to the sidebar via the conference
notification service.
1. sidebarByRefRequest/create message (Alice creates an
external 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:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. sidebarByRefResponse/create message (created
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-sidebarByRef-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971212@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>
</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:target method="dial-in"
uri="xcon-userid:David@example.com"/>
<xcon:target method="dial-in"
uri="xcon-userid:Ethel@example.com"/>
</xcon:allowed-users-list>
<xcon:sidebar-parent>
xcon:8977878@example.com
</xcon:sidebar-parent>
</info:users>
</sidebarByRefInfo>
</ccmp:sidebarByRefResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
3. sidebarByRefRequest/update message (Alice updates the sidebar)
<?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-sidebarByRef-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByRefRequest>
<sidebarByRefInfo entity="xcon:8971212@example.com">
<info:conference-description>
<info:display-text>
sidebar with Alice, Bob, Ethel and Fred
</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>inactive</info:status>
</info:entry>
<info:entry label="456">
<info:display-text>
main conference video
</info:display-text>
<info:type>video</info:type>
<info:status>inactive</info:status>
</info:entry>
<info:entry label="AUTO_GENERATE_1">
<info:display-text>
sidebar audio
</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</info:entry>
<info:entry label="AUTO_GENERATE_2">
<info:display-text>
sidebar 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>false</info:active> </info:conference-state> <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:target method="dial-out" uri="sip:fred@example.com"/> </xcon:allowed-users-list> </info:users> </sidebarByRefInfo> </ccmp:sidebarByRefRequest> </ccmpRequest> </ccmp:ccmpRequest> 4. sidebarByRefResponse/update message (sidebar updated) <?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:8971212@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 22: External Sidebar Messaging Details
(page 60 continued on part 4)