RFC 7058
Media Control Channel Framework (CFW) Call Flow Examples
Pages: 182
Informational
Informational
Part 3 of 6 – Pages 57 to 99
6.3. Conferencing
One of the most important services the MS must be able to provide is mixing. This involves mixing media streams from different sources and delivering the resulting mix(es) to each interested party, often according to per-user policies, settings, and encoding. A typical scenario involving mixing is, of course, media conferencing. In such a scenario, the media sent by each participant is mixed, and each participant typically receives the overall mix, excluding its own contribution and encoded in the format it negotiated. This example points out in a quite clear way how mixing must take care of the profile of each involved entity.
A media perspective of such a scenario is depicted in Figure 25. +-------+ | UAC | | C | +-------+ " ^ C (RTP) " " " " " " A+B (RTP) v " +-------+ A (RTP) +--------+ A+C (RTP) +-------+ | UAC |===================>| Media |===================>| UAC | | A |<===================| Server |<===================| B | +-------+ B+C (RTP) +--------+ B (RTP) +-------+ Figure 25: Conference: Media Perspective From the framework point of view, when the UACs' legs are not attached to anything yet, what appears is shown in Figure 26: since there are no connections involving the UACs yet, the frames they might be sending are discarded, and nothing is sent back to them (except for silence, if its transmission is requested). MS +----------------+ UAC A | | UAC B o----->>-------x x.......>>.....o o.....<<.......x x-------<<-----o | | | | | xx | | |. | +-------|.-------+ |. ^v ^v |. oo UAC C Figure 26: Conference: UAC Legs Not Attached
The next subsections will cover several typical scenarios involving
mixing and conferencing as a whole, specifically:
1. Simple Bridging scenario, which is a very basic (i.e., no
"special effects"; just mixing involved) conference involving one
or more participants.
2. Rich Conference scenario, which enriches the Simple Bridging
scenario by adding additional features typically found in
conferencing systems (e.g., DTMF collection for PIN-based
conference access, private and global announcements, recordings,
and so on).
3. Coaching scenario, which is a more complex scenario that involves
per-user mixing (customers, agents, and coaches don't all get the
same mixes).
4. Sidebars scenario, which adds more complexity to the previous
conferencing scenarios by involving sidebars (i.e., separate
conference instances that only exist within the context of a
parent conference instance) and the custom media delivery that
follows.
5. Floor Control scenario, which provides some guidance on how floor
control could be involved in a MEDIACTRL-based media conference.
All of the above-mentioned scenarios depend on the availability of a
mixing entity. Such an entity is provided in the Media Control
Channel Framework by the conferencing package. Besides allowing for
the interconnection of media sources as seen in the Direct Echo Test
section, this package enables the creation of abstract connections
that can be joined to multiple connections. These abstract
connections, called conferences, mix the contribution of each
attached connection and feed them accordingly (e.g., a connection
with a 'sendrecv' property would be able to contribute to the mix and
listen to it, while a connection with a 'recvonly' property would
only be able to listen to the overall mix but not actively contribute
to it).
That said, each of the above-mentioned scenarios will start more or less in the same way: by the creation of a conference connection (or more than one, as needed in some cases) to be subsequently referred to when it comes to mixing. A typical framework transaction to create a new conference instance in the Media Control Channel Framework is depicted in Figure 27: AS MS | | | 1. CONTROL (create conference) | |++++++++++++++++++++++++++++++++>>| | |--+ create | | | conf and | 2. 200 OK (conferenceid=Y) |<-+ its ID |<<++++++++++++++++++++++++++++++++| map URI +--| | X with | | | confY +->| | | | . . . . Figure 27: Conference: Framework Transactions The call flow is quite straightforward and can typically be summarized in the following steps: o The AS invokes the creation of a new conference instance by means of a CONTROL request (1); this request is addressed to the conferencing package (msc-mixer/1.0) and contains in the body the directive (<createconference>) with all the desired settings for the new conference instance. In the example below, the mixing policy is to mix the five ('reserved-talkers') loudest speakers (nbest), while ten listeners at maximum are allowed. Video settings are configured, including the mechanism used to select active video sources (<controller>, meaning the AS will explicitly instruct the MS about it) and details about the video layouts to make available. In this example, the AS is instructing the MS to use a <single-view> layout when only one video source is active, to pass to a <quad-view> layout when at least two video sources are active, and to use a <multiple-5x1> layout whenever the number of sources is at least five. Finally, the AS also subscribes to the "active-talkers" event, which means it wants to be informed (at a rate of 4 seconds) whenever an active participant is speaking.
o The MS creates the conference instance, assigns a unique
identifier to it (6146dd5), and completes the transaction with a
200 response (2).
o At this point, the requested conference instance is active and
ready to be used by the AS. It is then up to the AS to integrate
the use of this identifier in its application logic.
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 3032e5fb79a1 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 489
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="5" reserved-listeners="10">
<audio-mixing type="nbest"/>
<video-layouts>
<video-layout min-participants='1'>
<single-view/>
</video-layout>
<video-layout min-participants='2'>
<quad-view/>
</video-layout>
<video-layout min-participants='5'>
<multiple-5x1/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
<subscribe>
<active-talkers-sub interval="4"/>
</subscribe>
</createconference>
</mscmixer>
2. AS <- MS (CFW 200)
---------------------
CFW 3032e5fb79a1 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="6146dd5"/>
</mscmixer>
6.3.1. Simple Bridging
As mentioned previously, the simplest way that an AS can use a
conference instance is simple bridging. In this scenario, the
conference instance just acts as a bridge for all the participants
that are attached to it. The bridge takes care of transcoding, if
needed (in general, different participants may use different codecs
for their streams), echo cancellation (each participant will receive
the overall mix, excluding its own contribution) and per-participant
mixing (each participant may receive different mixed streams,
according to what it needs/is allowed to send/receive). This
assumes, of course, that each interested participant must be somehow
joined to the bridge in order to indirectly communicate with the
other participants. From the media perspective, the scenario can be
seen as depicted in Figure 28.
MS
+-----------------+
UAC A | | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: |
| |v |
| ++ |
| |: |
+--------|:-------+
|:
^v
^v
|:
oo
UAC C
Figure 28: Conference: Simple Bridging
In the framework, the first step is obviously to create a new conference instance as seen in the introductory section (Figure 27). Assuming that a conference instance has already been created, bridging participants to it is quite straightforward and can be accomplished as seen in the Direct Echo Test scenario. The only difference here is that each participant is not directly connected to itself (Direct Echo) or another UAC (Direct Connection) but to the bridge instead. Figure 29 shows the example of two different UACs joining the same conference. The example, as usual, hides the previous interaction between each of the two UACs and the AS, and instead focuses on what the AS does in order to actually join the participants to the bridge so that they can interact in a conference. Please note also that to make the diagram more readable, two different identifiers (UAC1 and UAC2) are used in place of the identifiers previously employed to introduce the scenario (UAC A, B, C). UAC1 UAC2 AS MS | | | | | | | A1. CONTROL (join UAC1 and confY) | | | |++++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC1 & | | | A2. 200 OK |<-+ confY | | |<<++++++++++++++++++++++++++++++++++| | | | | |<<######################################################>>| | Now UAC1 is mixed in the conference | |<<######################################################>>| | | | | | | | B1. CONTROL (join UAC2 and confY) | | | |++++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC2 & | | | B2. 200 OK |<-+ confY | | |<<++++++++++++++++++++++++++++++++++| | | | | | |<<###########################################>>| | | Now UAC2 too is mixed in the conference | | |<<###########################################>>| | | | | . . . . . . . . Figure 29: Simple Bridging: Framework Transactions (1)
The framework transaction steps are actually quite trivial and easy
to understand, since they're very similar to some previously
described scenarios. The AS joins both UAC1 (id1 in A1) and UAC2
(id1 in B1) to the conference (id2 in both transactions). As a
result of these two operations, both UACs are mixed in the
conference. Since no <stream> is explicitly provided in any of the
transactions, all the media from the UACs (audio/video) are attached
to the conference (as long as the conference has been properly
configured to support both, of course).
A1. AS -> MS (CFW CONTROL)
--------------------------
CFW 434a95786df8 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="e1e1427c:1c998d22" id2="6146dd5"/>
</mscmixer>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 434a95786df8 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
B1. AS -> MS (CFW CONTROL)
--------------------------
CFW 5c0cbd372046 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="6146dd5"/>
</mscmixer>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 5c0cbd372046 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
Once one or more participants have been attached to the bridge, their
connections and how their media are handled by the bridge can be
dynamically manipulated by means of another directive, called
<modifyjoin>. A typical use case for this directive is the change of
direction of an existing media (e.g., a previously speaking
participant is muted, which means its media direction changes from
'sendrecv' to 'recvonly'). Figure 30 shows how a framework
transaction requesting such a directive might appear.
UAC1 UAC2 AS MS
| | | |
| | | 1. CONTROL (modifyjoin UAC1) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modify
| | | | | join
| | | 2. 200 OK |<-+ settings
| | |<<++++++++++++++++++++++++++++++++|
| | | |
|<<######################################################|
| Now UAC1 can receive but not send (recvonly) |
|<<######################################################|
| | | |
. . . .
. . . .
Figure 30: Simple Bridging: Framework Transactions (2)
The directive used to modify an existing join configuration is
<modifyjoin>, and its syntax is exactly the same as the syntax
required in <join> instructions. In fact, the same syntax is used
for identifiers (id1/id2). Whenever a <modifyjoin> is requested and
id1 and id2 address one or more joined connections, the AS is
requesting a change of the join configuration. In this case, the AS
instructs the MS to mute (<stream> media=audio, direction=recvonly)
UAC1 (id1=UAC1) in the conference (id2) it has been attached to
previously. Any other connection existing between them is left
untouched.
It is worth noting that the <stream> settings are enforced according
to both the provided direction AND the id1 and id2 identifiers. For
instance, in this example id1 refers to UAC1, while id2 refers to the
conference in the MS. This means that the required modifications
have to be applied to the stream specified in the <stream> element of
the message, along the direction that goes from 'id1' to 'id2' (as
specified in the <modifyjoin> element of the message). In the
provided example, the AS wants to mute UAC1 with respect to the
conference. To do so, the direction is set to 'recvonly', meaning
that, for what affects id1, the media stream is only to be received.
If id1 referred to the conference and id2 to UAC1, to achieve the
same result the direction would have to be set to 'sendonly', meaning
"id1 (the conference) can only send to id2 (UAC1), and no media
stream must be received". Additional settings for a <stream> (e.g.,
audio volume, region assignments, and so on) follow the same
approach, as discussed in subsequent sections.
1. AS -> MS (CFW CONTROL)
-------------------------
CFW 57f2195875c9 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 182
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="e1e1427c:1c998d22" id2="6146dd5">
<stream media="audio" direction="recvonly"/>
</modifyjoin>
</mscmixer>
2. AS <- MS (CFW 200 OK)
------------------------
CFW 57f2195875c9 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
6.3.2. Rich Conference Scenario
The previous scenario can be enriched with additional features often
found in existing conferencing systems. Typical examples include
IVR-based menus (e.g., the DTMF collection for PIN-based conference
access), partial and complete recordings in the conference (e.g., for
the "state your name" functionality and recording of the whole conference), private and global announcements, and so on. All of this can be achieved by means of the functionality provided by the MS. In fact, even if the conferencing and IVR features come from different packages, the AS can interact with both of them and achieve complex results by correlating the effects of different transactions in its application logic. From the media and framework perspective, a typical Rich Conference scenario can be seen as depicted in Figure 31. MS +-------- (announcement.wav) (conference_recording.wav) <:::::+| :| +--------:|--------+ UAC A | :v | UAC B o----->>-------+~~~>{##}:::>+:::::::>>:::::o o:::::<<:::::::+<:::{##}<~~~+-------<<-----o | ^: | | | |v v | | ++ * (collect DTMF, get name) | |: | +--------|:--------+ |: ^v ^v |: oo UAC C Figure 31: Conference: Rich Conference Scenario To identify a single sample scenario, let's consider this sequence for a participant joining a conference (which again we assume has already been created): 1. The UAC as usual INVITEs a URI associated with a conference, and the AS follows the previously explained procedure to have the UAC negotiate a new media session with the MS. 2. The UAC is presented with an IVR menu, in which it is requested to input a PIN code to access the conference. 3. If the PIN is correct, the UAC is asked to state its name so that it can be recorded.
4. The UAC is attached to the conference, and the previously
recorded name is announced globally to the conference to
advertise its arrival.
Figure 32 shows a single UAC joining a conference. The example, as
usual, hides the previous interaction between the UAC and the AS, and
instead focuses on what the AS does to actually interact with the
participant and join it to the conference bridge.
UAC AS MS
| | |
| | A1. CONTROL (request DTMF PIN) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | A2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "Please input the PIN number to join the conference" |
|<<########################################################|
| | |
|########################################################>>|
| DTMF digits are collected |--+ get
|########################################################>>| | DTMF
| | |<-+ digits
| | B1. CONTROL (<collectinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Compare DTMF +--| B2. 200 OK |
| digits with | |++++++++++++++++++++++++++++++++>>|
| the PIN number +->| |
| | C1. CONTROL (record name) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ start
| | | | the
| | C2. 200 OK |<-+ dialog
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<########################################################|
| "Please state your name after the beep" |
|<<########################################################|
| | |
|########################################################>>|
| Audio from the UAC is recorded (until timeout or DTMF) |--+ save
|########################################################>>| | in a
| | |<-+ file
| | D1. CONTROL (<recordinfo>) |
| |<<++++++++++++++++++++++++++++++++|
| Store recorded +--| D2. 200 OK | | file to play | |++++++++++++++++++++++++++++++++>>| | announcement in +->| | | conference later | | | | E1. CONTROL (join UAC & confY) | | |++++++++++++++++++++++++++++++++>>| | | |--+ join | | | | UAC & | | E2. 200 OK |<-+ confY | |<+++++++++++++++++++++++++++++++++| | | | |<<######################################################>>| | UAC is now included in the mix of the conference | |<<######################################################>>| | | | | | F1. CONTROL (play name on confY) | | |++++++++++++++++++++++++++++++++>>| | | |--+ start | | | | the | | F2. 200 OK |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | | |<<########################################################| | Global announcement: "Simon has joined the conference" | |<<########################################################| | | | | | G1. CONTROL (<promptinfo>) | | |<<++++++++++++++++++++++++++++++++| | | G2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . . Figure 32: Rich Conference Scenario: Framework Transactions As can be deduced from the sequence diagram above, the AS, in its business logic, correlates the results of different transactions, addressed to different packages, to implement a conferencing scenario more complex than the Simple Bridging scenario previously described. The framework transaction steps are as follows: o Since this is a private conference, the UAC is to be presented with a request for a password, in this case a PIN number. To do so, the AS instructs the MS (A1) to collect a series of DTMF digits from the specified UAC (connectionid=UAC). The request includes both a voice message (<prompt>) and the described digit collection context (<collect>). The PIN is assumed to be a
4-digit number, and so the MS has to collect 4 digits maximum
(maxdigits=4). The DTMF digit buffer must be cleared before
collecting (cleardigitbuffer=true), and the UAC can use the star
key to restart the collection (escapekey=*), e.g., if the UAC is
aware that he mistyped any of the digits and wants to start again.
o The transaction goes on as usual (A2), with the transaction being
handled and notification of the dialog start being sent in a 200
OK. After that, the UAC is actually presented with the voice
message and is subsequently requested to input the required PIN
number.
o We assume that the UAC typed the correct PIN number (1234), which
is reported by the MS to the AS by means of the usual MS-generated
CONTROL event (B1). The AS correlates this event to the
previously started dialog by checking the referenced dialogid
(06d1bac) and acks the event (B2). It then extracts the
information it needs from the event (in this case, the digits
provided by the MS) from the <controlinfo> container (dtmf=1234)
and verifies that it is correct.
o Since the PIN is correct, the AS can proceed to the next step,
i.e., asking the UAC to state his name, in order to subsequently
play the recording on the conference to report the new
participant. Again, this is done with a request to the IVR
package (C1). The AS instructs the MS to play a voice message
("state your name after the beep"), to be followed by a recording
of only the audio from the UAC (in stream, media=audio/sendonly,
while media=video/inactive). A beep must be played right before
the recording starts (beep=true), and the recording must only last
3 seconds (maxtime=3s), since it is only needed as a brief
announcement.
o Without delving again into the details of a recording-related
transaction (C2), the AS finally gets the URI of the requested
recording (D1, acked in D2).
o At this point, the AS attaches the UAC (id1) to the conference
(id2), just as explained for the Simple Bridging scenario (E1/E2).
o Finally, to notify the other participants that a new participant
has arrived, the AS requests a global announcement on the
conference. This is a simple <prompt> request to the IVR package
(F1), as explained in previous sections (e.g., Section 6.1.2,
among others), but with a slight difference: the target of the
prompt is not a connectionid (a media connection) but the
conference itself (conferenceid=6146dd5). As a result of this
transaction, the announcement would be played on all the media
connections attached to the conference that are allowed to receive
media from it. The AS specifically requests that two media files
be played:
1. the media file containing the recorded name of the new user as
retrieved in D1 ("Simon...").
2. a pre-recorded media file explaining what happened ("... has
joined the conference").
The transaction then follows its usual flow (F2), and the event
that sends notification regarding the end of the announcement (G1,
acked in G2) concludes the scenario.
A1. AS -> MS (CFW CONTROL, collect)
-----------------------------------
CFW 50e56b8d65f9 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 311
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/prompts/conf-getpin.wav"
type="audio/x-wav"/>
</prompt>
<collect maxdigits="4" escapekey="*" cleardigitbuffer="true"/>
</dialog>
</dialogstart>
</mscivr>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 50e56b8d65f9 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="06d1bac"/>
</mscivr>
B1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 166d68a76659 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 272
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="06d1bac">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="2312" termmode="completed"/>
<collectinfo dtmf="1234" termmode="match"/>
</dialogexit>
</event>
</mscivr>
B2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 166d68a76659 200
C1. AS -> MS (CFW CONTROL, record)
----------------------------------
CFW 61fd484f196e CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 373
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="10514b7f:6a900179">
<dialog>
<prompt>
<media
loc="http://www.example.net/prompts/conf-rec-name.wav"
type="audio/x-wav"/>
</prompt>
<record beep="true" maxtime="3s"/>
</dialog>
<stream media="audio" direction="sendonly"/>
<stream media="video" direction="inactive"/>
</dialogstart>
</mscivr>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 61fd484f196e 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="1cf0549"/>
</mscivr>
D1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 3ec13ab96224 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 402
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="1cf0549">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="4988" termmode="completed"/>
<recordinfo duration="3000" termmode="maxtime">
<mediainfo
loc="http://www.example.net/recordings/recording-1cf0549.wav"
type="audio/x-wav" size="48044"/>
</recordinfo>
</dialogexit>
</event>
</mscivr>
D2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 3ec13ab96224 200
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 261d188b63b7 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 120
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="6146dd5"/>
</mscmixer>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 261d188b63b7 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
F1. AS -> MS (CFW CONTROL, play)
--------------------------------
CFW 718c30836f38 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 334
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart conferenceid="6146dd5">
<dialog>
<prompt>
<media
loc="http://www.example.net/recordings/recording-1cf0549.wav"
type="audio/x-wav"/>
<media
loc="http://www.example.net/prompts/conf-hasjoin.wav"
type="audio/x-wav"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
F2. AS <- MS (CFW 200 OK)
-------------------------
CFW 718c30836f38 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 137
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="200" reason="Dialog started" dialogid="5f4bc7e"/>
</mscivr>
G1. AS <- MS (CFW CONTROL event)
--------------------------------
CFW 6485194f622f CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 229
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<event dialogid="5f4bc7e">
<dialogexit status="1" reason="Dialog successfully completed">
<promptinfo duration="1838" termmode="completed"/>
</dialogexit>
</event>
</mscivr>
G2. AS -> MS (CFW 200, ACK to 'CONTROL event')
----------------------------------------------
CFW 6485194f622f 200
6.3.3. Coaching Scenario
Another typical conference-based use case is the so-called Coaching
scenario. In such a scenario, a customer (called "A" in the
following example) places a call to a business call center. An agent
(B) is assigned to the customer. A coach (C), who cannot be heard by
the customer, provides the agent with whispered suggestions about
what to say. This scenario is also described in [RFC4597].
As can be deduced from the scenario description, per-user policies
for media mixing and delivery, i.e., who can hear what, are very
important. The MS must make sure that only the agent can hear the
coach's suggestions. Since this is basically a multiparty call
(despite what the customer might be thinking), a mixing entity is
needed in order to accomplish the scenario requirements. To
summarize:
o The customer (A) must only hear what the agent (B) says.
o The agent (B) must be able to hear both A and the coach (C).
o C must be able to hear both A and B in order to give B the right
suggestions and also be aware of the whole conversation.
From the media and framework perspective, such a scenario can be seen as depicted in Figure 33. ************** +-------+ * A=Customer * | UAC | * B=Agent * | C | * C=Coach * +-------+ ************** " ^ C (RTP) " " " " " " A+B (RTP) v " +-------+ A (RTP) +--------+ A+C (RTP) +-------+ | UAC |===================>| Media |===================>| UAC | | A |<===================| Server |<===================| B | +-------+ B (RTP) +--------+ B (RTP) +-------+ Figure 33: Coaching Scenario: Media Perspective From the framework point of view, when the previously mentioned legs are not attached to anything yet, what appears is shown in Figure 34. MS +---------------------------+ | | UAC A | | UAC B o.....<<.......x x-------<<-----o o----->>-------x x.......>>.....o | | | | | | | | | xx | | .| + +------------v^-------------+ v^ .| .| oo UAC C Figure 34: Coaching Scenario: UAC Legs Not Attached By contrast, what the scenario should look like is depicted in Figure 35. The customer receives media directly from the agent ('recvonly'), while all of the three involved participants contribute to a hidden conference. Of course, the customer is not allowed to
receive the mixed flows from the conference ('sendonly'), unlike the
agent and the coach, who must both be aware of the whole conversation
('sendrecv').
MS
+---------------------------+
| |
UAC A | | UAC B
o-----<<-------+----<<----+----<<----+-------<<-----o
o----->>-------+ | +------->>-----o
| | v ^ |
| +~~~~~~~>[##]::::>::::+ |
| v^ |
| || |
| ++ |
| :| +
+------------v^-------------+
v^
:|
:|
oo
UAC C
Figure 35: Coaching Scenario: UAC Legs Mixed and Attached
In the framework, this can be achieved by means of the Mixer Control
Package, which, as demonstrated in the previous conferencing
examples, can be exploited whenever mixing and joining entities are
needed. The needed steps can be summarized in the following list:
1. First of all, a hidden conference is created.
2. Then, the three participants are all attached to it, each with a
custom mixing policy, specifically:
* the customer (A) as 'sendonly'.
* the agent (B) as 'sendrecv'.
* the coach (C) as 'sendrecv' and with a gain of -3 dB to halve
the volume of its own contribution (so that the agent actually
hears the customer at a louder volume and hears the coach
whispering).
3. Finally, the customer is joined to the agent as a passive
receiver ('recvonly').
A diagram of such a sequence of transactions is depicted in Figure 36: A B C AS MS | | | | | | | | | A1. CONTROL (create conference) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ create | | | | | | conf and | | | | A2. 200 OK (conferenceid=Y) |<-+ its ID | | | |<<++++++++++++++++++++++++++++++++| | | | | | | | | | B1. CONTROL (join A-->confY) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ join A | | | | | | & confY | | | | B2. 200 OK |<-+ sendonly | | | |<<++++++++++++++++++++++++++++++++| | | | | | |######################################################>>| | Customer (A) is mixed (sendonly) in the conference | |######################################################>>| | | | | | | | | | C1. CONTROL (join B<->confY) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ join B | | | | | | & confY | | | | C2. 200 OK |<-+ sendrecv | | | |<<++++++++++++++++++++++++++++++++| | | | | | | |<<#############################################>>| | | Agent (B) is mixed (sendrecv) in the conference | | |<##############################################>>| | | | | | | | | | D1. CONTROL (join C<->confY) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ join C | | | | | | & confY | | | | D2. 200 OK |<-+ sendrecv | | | |<<++++++++++++++++++++++++++++++++| | | | | | | | |<<######################################>>| | | | Coach (C) is mixed (sendrecv) as well | | | |<<######################################>>| | | | | |
| | | | E1. CONTROL (join A<--B) | | | | |++++++++++++++++++++++++++++++++>>| | | | | |--+ join | | | | | | A & B | | | | E2. 200 OK |<-+ recvonly | | | |<<++++++++++++++++++++++++++++++++| | | | | | |<<######################################################| | Finally, Customer (A) is joined (recvonly) to Agent (B)| |<<######################################################| | | | | | . . . . . . . . . . Figure 36: Coaching Scenario: Framework Transactions o First of all, the AS creates a new hidden conference by means of a <createconference> request (A1). This conference is properly configured according to the use it is assigned to, i.e., to mix all the involved parties accordingly. Since only three participants will be joined to it, 'reserved-talkers' is set to 3. 'reserved-listeners', on the other hand, is set to 2, since only the agent and the coach must receive a mix, while the customer must be unaware of the coach. Finally, the video layout is set to <dual-view> for the same reason, since only the customer and the agent must appear in the mix. o The MS sends notification of the successful creation of the new conference in a 200 framework message (A2). The identifier assigned to the conference, which will be used in subsequent requests addressed to it, is 1df080e. o Now that the conference has been created, the AS joins the three actors to it with different policies, namely (i) the customer (A) is joined as 'sendonly' to the conference (B1), (ii) the agent (B) is joined as 'sendrecv' to the conference (C1), and (iii) the coach (C) is joined as 'sendrecv' (but audio only) to the conference and with a lower volume (D1). The custom policies are enforced by means of properly constructed <stream> elements. o The MS takes care of the requests and acks them (B2, C2, D2). At this point, the conference will receive media from all the actors but only provide the agent and the coach with the resulting mix.
o To complete the scenario, the AS joins A with B directly as
'recvonly' (E1). The aim of this request is to provide A with
media too, namely the media contributed by B. This way, A is
unaware of the fact that its media are accessed by C by means of
the hidden mixer.
o The MS takes care of this request too and acks it (E2), concluding
the scenario.
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 329
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="3" reserved-listeners="2">
<audio-mixing type="nbest"/>
<video-layouts>
<video-layout min-participants='1'>
<dual-view/>
</video-layout>
</video-layouts>
<video-switch>
<controller/>
</video-switch>
</createconference>
</mscmixer>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 238e1f2946e8 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="1df080e"/>
</mscmixer>
B1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 2eb141f241b7 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 226
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="1df080e">
<stream media="audio" direction="sendonly"/>
<stream media="video" direction="sendonly"/>
</join>
</mscmixer>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 2eb141f241b7 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
C1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 122
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="756471213:c52ebf1b" id2="1df080e"/>
</mscmixer>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
D1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 221
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="z9hG4bK19461552:1353807a" id2="1df080e">
<stream media="audio">
<volume controltype="setgain" value="-3"/>
</stream>
</join>
</mscmixer>
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
E1. AS -> MS (CFW CONTROL, join)
--------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml
Content-Length: 236
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="10514b7f:6a900179" id2="756471213:c52ebf1b">
<stream media="audio" direction="recvonly"/>
<stream media="video" direction="recvonly"/>
</join>
</mscmixer>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
6.3.4. Sidebars
Within the context of conferencing, there could be a need for
so-called sidebars, or side conferences. This would be the case, for
instance, if two or more participants of a conference were willing to
create a side conference among each other while still receiving part
of the original conference mix in the background. Motivations for
such a use case can be found in both [RFC4597] and [RFC5239]. It is
clear that in such a case the side conference is actually a separate
conference but must also somehow be related to the original
conference. Although the application-level relationship is out of
scope for this document (this "belongs" to Centralized Conferencing
(XCON)), the media stream relationship is more relevant here, because
there is a stronger relationship at the media level from the
MEDIACTRL point of view. Consequently, it is interesting to analyze
how sidebars could be used to construct the conference mixes
according to the MEDIACTRL specification.
The scenario presented in this section is a conference hosting four
different participants: A, B, C, and D. All these participants are
attached to the conference as active senders and receivers of the
existing media streams. At a certain point in time, two participants
(B and D) decide to create a sidebar just for them. The sidebar they want to create is constructed so that only audio is involved. The audio mix of the sidebar must not be made available to the main conference. The mix of the conference must be attached to the sidebar, but with a lower volume (30%), because it is just background to the actual conversation. This would allow both B and D to talk to each other without A and C listening to them, while B and D could still have an overview of what's happening in the main conference. From the media and framework perspective, such a scenario can be seen as depicted in Figure 37. +-------+ | UAC | | C | +-------+ " ^ C (RTP) " " " " " " A (RTP) v " +-------+ A (RTP) +--------+ D+[a+c] (RTP) +-------+ | UAC |===================>| Media |===================>| UAC | | A |<===================| Server |<===================| B | +-------+ C (RTP) +--------+ B (RTP) +-------+ ^ " " " B+[a+c] (RTP) " " D (RTP) " " " v +-------+ | UAC | | D | +-------+ Figure 37: Sidebars: Media Perspective
From the framework point of view, when all the participants are attached to the main conference, what appears is shown in Figure 38. UAC C oo :| ^v ^v :| +--------:|-------+ | :| | | ++ | UAC A | ^| | UAC B o----->>-------+~~~>{##}:::>+:::::::>>:::::o o:::::<<:::::::+<:::{##}<~~~+-------<<-----o | ^: | | |v | | ++ | | |: | +--------|:-------+ |: ^v ^v |: oo UAC D Figure 38: Sidebars: UAC Legs in Main Conference By contrast, what the scenario should look like is depicted in Figure 39. A new mixer is created to host the sidebar. The main mix is then attached as 'sendonly' to the sidebar mix at a lower volume (in order to provide the sidebar users with a background of the main conference). The two interested participants (B and D) have their audio leg detached from the main conference and attached to the sidebar. This detachment can be achieved by either actually detaching the leg or just modifying the status of the leg to 'inactive'. Note that this only affects the audio stream: the video of the two users is still attached to the main conference, and what happens at the application level may or may not have been changed accordingly (e.g., XCON protocol interactions). Please note that the main conference is assumed to be in place and the involved participants (A, B, C, and D) attached ('sendrecv') to it.
UAC C oo :| ^v ^v :| +--------:|----------------+ | :| | | ++ | UAC A | ^| | UAC B o----->>-------+~~~>{##}:::>{##}:::>+:::::::>>:::::o o:::::<<:::::::+<:::{##} {##}<~~~+-------<<-----o | ^: | | ++ | | |v | +----------------|:--------+ |: ^v ^v |: oo UAC D Figure 39: Sidebars: UAC Legs Mixed and Attached The situation may subsequently be reverted (e.g., destroying the sidebar conference and reattaching B and D to the main conference mix) in the same way. The AS would just need to unjoin B and D from the hidden conference and change their connection with the main conference back to 'sendrecv'. After unjoining the main mix and the sidebar mix, the sidebar conference could then be destroyed. For brevity, and because similar transactions have already been presented, these steps are not described here. In the framework, just as in the previous section, the presented scenario can again be achieved by means of the Mixer Control Package. The needed steps can be summarized in the following list: 1. First of all, a hidden conference is created (the sidebar mix). 2. Then, the main conference mix is attached to it as 'sendonly' and with a gain of -5 dB to limit the volume of its own contribution to 30% (so that B and D can hear each other at a louder volume while still listening to what's happening in the main conference in the background).
3. B and D are detached from the main mix for audio (<modifyjoin>
with 'inactive' status).
4. B and D are attached to the hidden sidebar mix for audio.
Note that for detaching B and D from the main mix, a <modifyjoin>
with an 'inactive' status is used, instead of an <unjoin>. The
motivation for this is related to how a subsequent rejoining of B and
D to the main mix could take place. In fact, by using <modifyjoin>
the resources created when first joining B and D to the main mix
remain in place, even if marked as unused at the moment. An
<unjoin>, on the other hand, would actually free those resources,
which in turn could be granted to other participants joining the
conference in the meantime. This means that when needing to reattach
B and D to the main mix, the MS may not have the resources to do so,
resulting in an undesired failure.
A diagram of such a sequence of transactions (where confX is the
identifier of the pre-existing main conference mix) is depicted in
Figure 40:
B D AS MS
| | | |
| | | A1. CONTROL (create conference) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ create
| | | | | conf and
| | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | B1. CONTROL (join confX-->confY) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ join confX
| | | | | & confY
| | | B2. 200 OK |<-+ sendonly
| | |<<++++++++++++++++++++++++++++++++| (30% vol)
| | | |
| | | C1. CONTROL (modjoin B---confX) |
| | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modjoin B
| | | | | & confX
| | | C2. 200 OK |<-+ (inactive)
| | |<<++++++++++++++++++++++++++++++++|
| | | |
| | | D1. CONTROL (join B<-->confY) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ join B | | | | | & confY | | | D2. 200 OK |<-+ sendrecv | | |<<++++++++++++++++++++++++++++++++| (audio) | | | | |<<##################################################>>| | Participant B is mixed (sendrecv) in the sidebar | | (A, C, and D can't listen to her/him anymore) | |<<##################################################>>| | | | | | | | E1. CONTROL (modjoin D---confX) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ modjoin D | | | | | & confX | | | E2. 200 OK |<-+ (inactive) | | |<<++++++++++++++++++++++++++++++++| | | | | | | | F1. CONTROL (join D<-->confY) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ join D | | | | | & confY | | | F2. 200 OK |<-+ sendrecv | | |<<++++++++++++++++++++++++++++++++| (audio) | | | | | |<<########################################>>| | | D is mixed (sendrecv) in the sidebar too | | | (A and C can't listen to her/him anymore) | | |<<########################################>>| | | | . . . . . . Figure 40: Sidebars: Framework Transactions o First of all, the hidden conference mix is created (A1). The request is basically the same as that presented in previous sections, i.e., a <createconference> request addressed to the Mixer package. The request is very lightweight and asks the MS to only reserve two listener seats ('reserved-listeners', since only B and D have to hear something) and three talker seats ('reserved-listeners', because in addition to B and D the main mix is also an active contributor to the sidebar). The mixing will be driven by directives from the AS (mix-type=controller). When the mix is successfully created, the MS provides the AS with its identifier (519c1b9).
o As a first transaction after that, the AS joins the audio from the
main conference and the newly created sidebar conference mix (B1).
Only audio needs to be joined (media=audio), with a 'sendonly'
direction (i.e., only flowing from the main conference to the
sidebar and not vice versa) and at 30% volume with respect to the
original stream (setgain=-5 dB). A successful completion of the
transaction is reported to the AS (B2).
o At this point, the AS makes the connection of B (2133178233:
18294826) and the main conference (2f5ad43) inactive by means of a
<modifyjoin> directive (C1). The request is taken care of by the
MS (C2), and B is actually excluded from the mix for sending as
well as receiving.
o After that, the AS (D1) joins B (2133178233:18294826) to the
sidebar mix created previously (519c1b9). The MS attaches the
requested connections and sends confirmation to the AS (D2).
o The same transactions already done for B are done for D as well
(id1=1264755310:2beeae5b), i.e., the <modifyjoin> to make the
connection in the main conference inactive (E1-2) and the <join>
to attach D to the sidebar mix (F1-2). At the end of these
transactions, A and C will only listen to each other, while B and
D will listen to each other and to the conference mix as a
comfortable background.
A1. AS -> MS (CFW CONTROL, createconference)
--------------------------------------------
CFW 7fdcc2331bef CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 198
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference reserved-talkers="3" reserved-listeners="2">
<audio-mixing type="controller"/>
</createconference>
</mscmixer>
A2. AS <- MS (CFW 200 OK)
-------------------------
CFW 7fdcc2331bef 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 151
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Conference created"
conferenceid="519c1b9"/>
</mscmixer>
B1. AS -> MS (CFW CONTROL, join with setgain)
---------------------------------------------
CFW 4e6afb6625e4 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 226
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="2f5ad43" id2="519c1b9">
<stream media="audio" direction="sendonly">
<volume controltype="setgain" value="-5"/>
</stream>
</join>
</mscmixer>
B2. AS <- MS (CFW 200 OK)
-------------------------
CFW 4e6afb6625e4 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
C1. AS -> MS (CFW CONTROL, modifyjoin with 'inactive' status)
-----------------------------------------------------------
CFW 3f2dba317c83 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 193
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="2133178233:18294826" id2="2f5ad43">
<stream media="audio" direction="inactive"/>
</modifyjoin>
</mscmixer>
C2. AS <- MS (CFW 200 OK)
-------------------------
CFW 3f2dba317c83 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
D1. AS -> MS (CFW CONTROL, join to sidebar)
-------------------------------------------
CFW 2443a8582d1d CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 181
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="2133178233:18294826" id2="519c1b9">
<stream media="audio" direction="sendrecv"/>
</join>
</mscmixer>
D2. AS <- MS (CFW 200 OK)
-------------------------
CFW 2443a8582d1d 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
E1. AS -> MS (CFW CONTROL, modifyjoin with 'inactive' status)
-----------------------------------------------------------
CFW 436c6125628c CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 193
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1264755310:2beeae5b" id2="2f5ad43">
<stream media="audio" direction="inactive"/>
</modifyjoin>
</mscmixer>
E2. AS <- MS (CFW 200 OK)
-------------------------
CFW 436c6125628c 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
F1. AS -> MS (CFW CONTROL, join to sidebar)
-------------------------------------------
CFW 7b7ed00665dd CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 181
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1264755310:2beeae5b" id2="519c1b9">
<stream media="audio" direction="sendrecv"/>
</join>
</mscmixer>
F2. AS <- MS (CFW 200 OK)
-------------------------
CFW 7b7ed00665dd 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/>
</mscmixer>
6.3.5. Floor Control
As described in [RFC4597], floor control is a feature typically
needed and employed in most conference scenarios. In fact, while not
a mandatory feature to implement when realizing a conferencing
application, it provides additional control of the media streams
contributed by participants, thus allowing for moderation of the
available resources. The Centralized Conferencing (XCON) framework
[RFC5239] suggests the use of the Binary Floor Control Protocol
(BFCP) [RFC4582] to achieve the aforementioned functionality. That
said, a combined use of floor control functionality and the tools
made available by the MEDIACTRL specification for conferencing would
definitely be interesting to investigate. [RFC5567] introduces two
different approaches to integrating floor control with the MEDIACTRL
architecture: (i) a topology where the floor control server is
co-located with the AS and (ii) a topology where the floor control
server is co-located with the MS. The two approaches are obviously
different with respect to the amount of information the AS and the MS
have to deal with, especially when thinking about the logic behind
the floor queues and automated decisions. Nevertheless, considering
how the Media Control Channel Framework is conceived, approach (ii)
would need a dedicated package (be it an extension or a totally new
package) in order to make the MS aware of floor control and allow the
MS to interact with the interested UAC accordingly. At the time of writing, such a package doesn't exist yet, and as a consequence only approach (i) will be dealt with in the presented scenario. The scenario will then assume that the Floor Control Server (FCS) is co-located with the AS. This means that all the BFCP requests will be sent by Floor Control Participants (FCPs) to the FCS, which will make the AS directly aware of the floor statuses. For the sake of simplicity, the scenario assumes that the involved participants are already aware of all the identifiers needed in order to make BFCP requests for a specific conference. Such information may have been carried according to the COMEDIA negotiation as specified in [RFC4583]. It is important to note that such information must not reach the MS. This means that within the context of the 3PCC mechanism that may have been used in order to attach a UAC to the MS, all the BFCP-related information negotiated by the AS and the UAC must be removed before making the negotiation available to the MS, which may be unable to understand the specification. A simplified example of how this could be achieved is presented in Figure 41. Please note that within the context of this example scenario, different identifiers may be used to address the same entity. Specifically, in this case the UAC (the endpoint sending and receiving media) is also a FCP, as it negotiates a BFCP channel too.
UAC AS (FCP) (FCS) MS | | | | INVITE (SDP: RTP+BFCP) | | |-------------------------------->| | | | INVITE (SDP: RTP) | | |-------------------------------->| | | 200 (SDP: RTP'+labels) | | |<--------------------------------| | match +--| | | floors | | | | & labels +->| | | | | | 200 (SDP: RTP'+BFCP'+labels) | | |<--------------------------------| | | ACK | | |-------------------------------->| | | | ACK | | |-------------------------------->| | | | |<<###################### RTP MEDIA STREAMS ######################>>| | | | |<<******** BFCP CHANNEL *******>>| | | | | . . . . . . Figure 41: Floor Control: Example of Negotiation
From the media and framework perspective, such a scenario doesn't differ much from the conferencing scenarios presented earlier. It is more interesting to focus on the chosen topology for the scenario, as depicted in Figure 42. +-------+ +--------+ | UAC | | AS | +-------+ | (FCP) |<****** BFCP ******>| (FCS) |<****** BFCP *******>| (FCC) | +-------+ +--------+ +-------+ ^ ^ | | | CFW | | | | v | +--------+ +----------RTP---------->| MS | +--------+ Figure 42: Floor Control: Overall Perspective The AS, besides maintaining the already-known SIP signaling among the involved parties, also acts as the FCS for the participants in the conferences for which it is responsible. In the scenario, two Floor Control Participants are involved: a basic Participant (FCP) and a Chair (FCC). As in all of the previously described conferencing examples, in the framework this can be achieved by means of the Mixer Control Package. Assuming that the conference has been created, the participant has been attached ('recvonly') to it, and the participant is aware of the involved BFCP identifiers, the needed steps can be summarized in the following list: 1. The assigned chair, FCC, sends a subscription for events related to the floor for which it is responsible (FloorQuery). 2. The FCP sends a BFCP request (FloorRequest) to access the audio resource ("I want to speak"). 3. The FCS (AS) sends a provisional response to the FCP (FloorRequestStatus PENDING) and handles the request in its queue. Since a chair is assigned to this floor, the request is forwarded to the FCC for a decision (FloorStatus). 4. The FCC makes a decision and sends it to the FCS (ChairAction ACCEPTED).
5. The FCS takes note of the decision and updates the queue
accordingly. The decision is sent to the FCP (FloorRequestStatus
ACCEPTED). The floor has not been granted yet.
6. As soon as the queue allows it, the floor is actually granted to
the FCP. The AS, which is co-located with the FCS, understands
in its business logic that such an event is associated with the
audio resource being granted to the FCP. As a consequence, a
<modifyjoin> ('sendrecv') is sent through the Control Channel to
the MS in order to unmute the FCP UAC in the conference.
7. The FCP is notified of this event (FloorRequestStatus GRANTED),
thus ending the scenario.
A diagram of such a sequence of transactions (also involving the BFCP
message flow at a higher level) is depicted in Figure 43:
UAC1 UAC2 AS
(FCP) (FCC) (FCS) MS
| | | |
|<<####################################################|
| UAC1 is muted (recvonly stream) in the conference |
|<<####################################################|
| | | |
| | FloorQuery |
| |*******>>| |
| | |--+ handle |
| | | | subscription |
| | |<-+ |
| | FloorStatus |
| |<<*******| |
| | | |
| FloorRequest | |
|*****************>>| |
| | |--+ handle |
| | | | request |
| Pending |<-+ (queue) |
|<<*****************| |
| | | |
| | FloorStatus |
| |<<*******| |
| | | |
| | ChairAction (ACCEPT) |
| |*******>>| | | | ChairActionAck | | |<<*******| | | | |--+ handle | | | | | decision | | | |<-+ (queue) | | Accepted | | |<<*****************| | | | FloorStatus | | |<<*******| | | | | | | | |--+ queue | | | | | grants | | | |<-+ floor | | | | | | | | 1. CONTROL (modjoin UAC<->conf) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ modjoin | | | | | UAC & conf | | | 2. 200 OK |<-+ (sendrecv) | | |<<++++++++++++++++++++++++++++++++| | | | | |<<##################################################>>| | UAC1 is now unmuted (sendrecv) in the conference | | and can speak, contributing to the mix | |<<##################################################>>| | | | | | Granted | | |<<*****************| | | | FloorStatus | | |<<*******| | | | | | . . . . . . Figure 43: Floor Control: Framework Transactions As can easily be deduced from the above diagram, the complex interaction at the BFCP level only results in a single transaction at the MEDIACTRL level. In fact, the purpose of the BFCP transactions is to moderate access to the audio resource, which means providing the event trigger to MEDIACTRL-based conference manipulation
transactions. Before being granted the floor, the FCP UAC is
excluded from the conference mix at the MEDIACTRL level ('recvonly').
As soon as the floor has been granted, the FCP UAC is included in the
mix. In MEDIACTRL words:
o Since the FCP UAC must be included in the audio mix, a
<modifyjoin> is sent to the MS in a CONTROL directive. The
<modifyjoin> has as identifiers the connectionid associated with
the FCP UAC (e1e1427c:1c998d22) and the conferenceid of the mix
(cf45ee2). The <stream> element tells the MS that the audio media
stream between the two must become bidirectional ('sendrecv'),
changing the previous status ('recvonly'). Please note that in
this case only audio was involved in the conference; if video were
involved as well, and video had to be unchanged, a <stream>
directive for video had to be placed in the request as well in
order to maintain its current status.
1. AS -> MS (CFW CONTROL)
-------------------------
CFW gh67ffg56w21 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 182
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="e1e1427c:1c998d22" id2="cf45ee2">
<stream media="audio" direction="sendrecv"/>
</modifyjoin>
</mscmixer>
2. AS <- MS (CFW 200 OK)
------------------------
CFW gh67ffg56w21 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 123
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join modified"/>
</mscmixer>
(page 99 continued on part 4)