rfc7058.txt   rfc7058-with-punct-fixes.txt 
skipping to change at page 3, line 41 skipping to change at page 3, line 41
In the next paragraphs, a brief overview of our implementation In the next paragraphs, a brief overview of our implementation
approach is described, with particular focus on protocol-related approach is described, with particular focus on protocol-related
aspects. This involves state diagrams that depict both the client aspects. This involves state diagrams that depict both the client
side (the AS) and the server side (the MS). Of course, this section side (the AS) and the server side (the MS). Of course, this section
is not at all to be considered a mandatory approach to the is not at all to be considered a mandatory approach to the
implementation of the framework. It is only meant to help readers implementation of the framework. It is only meant to help readers
understand how the framework works from a practical point of view. understand how the framework works from a practical point of view.
Once done with these preliminary considerations, in the subsequent Once done with these preliminary considerations, in the subsequent
sections real-life scenarios are addressed. In this context, first sections real-life scenarios are addressed. In this context, first
of all, the establishment of the Control Channel is dealt with: after of all, the establishment of the Control Channel is dealt with.
that, some use-case scenarios involving the most typical multimedia After that, some use-case scenarios involving the most typical
applications are depicted and described. multimedia applications are depicted and described.
It is worth pointing out that this document is not meant in any way It is worth pointing out that this document is not meant in any way
to be a self-contained guide to implementing a MEDIACTRL-compliant to be a self-contained guide to implementing a MEDIACTRL-compliant
framework. The specifications are a mandatory read for all framework. The specifications are a mandatory read for all
implementors, especially because this document follows their implementors, especially because this document follows their
guidelines but does not delve into the details of every aspect of the guidelines but does not delve into the details of every aspect of the
protocol. protocol.
2. Conventions 2. Conventions
Note that due to RFC formatting conventions, SIP/SDP and CFW lines Note that due to RFC formatting conventions, SIP/SDP and CFW lines
whose content exceeds 72 characters are split across lines. This whose content exceeds 72 characters are split across lines. This
line folding is marked by a backslash at the end of the first line. line folding is marked by a backslash at the end of the first line.
This backslash, the preceding whitespace, the following CRLF, and the This backslash, the preceding whitespace, the following CRLF, and the
whitespace beginning the next line would not appear in the actual whitespace beginning the next line would not appear in the actual
protocol contents. Note also that the indentation of the XML content protocol contents. Note also that the indentation of the XML content
is only provided for readability: actual messages will follow strict is only provided for readability. Actual messages will follow strict
XML syntax, which allows, but does not require, indentation. Due to XML syntax, which allows, but does not require, indentation. Due to
the same limit of 72 characters per line, this document also the same limit of 72 characters per line, this document also
sometimes splits the content of XML elements across lines: please be sometimes splits the content of XML elements across lines. Please be
aware that when this happens, no whitespace is actually meant to be aware that when this happens, no whitespace is actually meant to be
at either the beginning or the end of the element content. at either the beginning or the end of the element content.
Note also that a few diagrams show arrows that go from a network Note also that a few diagrams show arrows that go from a network
entity to itself. It's worth pointing out that such arrows do not entity to itself. It's worth pointing out that such arrows do not
represent any transaction message but are rather meant as an represent any transaction message but are rather meant as an
indication to the reader that the involved network entity made a indication to the reader that the involved network entity made a
decision, within its application logic, according to the input it decision, within its application logic, according to the input it
previously received. previously received.
skipping to change at page 5, line 39 skipping to change at page 5, line 39
In this section, we present an "informal" view of the main MEDIACTRL In this section, we present an "informal" view of the main MEDIACTRL
protocol interactions, in the form of state diagrams. Each diagram protocol interactions, in the form of state diagrams. Each diagram
is indeed a classical representation of a Mealy automaton, comprising is indeed a classical representation of a Mealy automaton, comprising
a number of possible protocol states, indicated with rectangular a number of possible protocol states, indicated with rectangular
boxes. Transitions between states are indicated through edges, with boxes. Transitions between states are indicated through edges, with
each edge labeled with a slash-separated pair representing a specific each edge labeled with a slash-separated pair representing a specific
input together with the associated output (a dash in the output input together with the associated output (a dash in the output
position means that, for that particular input, no output is position means that, for that particular input, no output is
generated from the automaton). Some of the inputs are associated generated from the automaton). Some of the inputs are associated
with MEDIACTRL protocol messages arriving at a MEDIACTRL component with MEDIACTRL protocol messages arriving at a MEDIACTRL component
while it is in a certain state: this is the case for 'CONTROL', while it is in a certain state. This is the case for 'CONTROL',
'REPORT' (in its various "flavors" -- pending, terminate, etc.), 'REPORT' (in its various "flavors" -- pending, terminate, etc.),
'200', '202', and 'Error' (error messages correspond to specific '200', '202', and 'Error' (error messages correspond to specific
numeric codes). Further inputs represent triggers arriving at the numeric codes). Further inputs represent triggers arriving at the
MEDIACTRL automaton from the upper layer, namely the Application MEDIACTRL automaton from the upper layer, namely the Application
Programming Interface used by programmers while implementing Programming Interface used by programmers while implementing
MEDIACTRL-enabled services: such inputs have been indicated with the MEDIACTRL-enabled services. Such inputs have been indicated with the
term 'API' followed by the message that the API itself is triggering term 'API' followed by the message that the API itself is triggering
(as an example, 'API terminate' is a request to send a 'REPORT' (as an example, 'API terminate' is a request to send a 'REPORT'
message with a status of 'terminate' to the peering component). message with a status of 'terminate' to the peering component).
Four diagrams are provided. Two of them (Figures 1 and 2) describe Four diagrams are provided. Two of them (Figures 1 and 2) describe
normal operation of the framework. Figure 3 contains two diagrams normal operation of the framework. Figure 3 contains two diagrams
describing asynchronous event notifications. Figure 1 embraces the describing asynchronous event notifications. Figure 1 embraces the
MS perspective, whereas Figure 2 shows the AS side. The upper part MS perspective, whereas Figure 2 shows the AS side. The upper part
of Figure 3 shows how events are generated, on the MS side, by of Figure 3 shows how events are generated, on the MS side, by
issuing a CONTROL message addressed to the AS; events are issuing a CONTROL message addressed to the AS; events are
acknowledged by the AS through standard 200 responses. Hence, the acknowledged by the AS through standard 200 responses. Hence, the
behavior of the AS, which mirrors that of the MS, is depicted in the behavior of the AS, which mirrors that of the MS, is depicted in the
lower part of the figure. lower part of the figure.
Coming back to Figure 1, the diagram shows that the MS activates upon Coming back to Figure 1, the diagram shows that the MS activates upon
reception of CONTROL messages coming from the AS; the CONTROL reception of CONTROL messages coming from the AS. The CONTROL
messages instruct the MS regarding the execution of a specific messages instruct the MS regarding the execution of a specific
command that belongs to one of the available Control Packages. The command that belongs to one of the available Control Packages. The
execution of the received command can either be quick or require some execution of the received command can either be quick or require some
time. In the former case, right after completing its operation, the time. In the former case, right after completing its operation, the
MS sends back to the AS a 200 message, which basically acknowledges MS sends back to the AS a 200 message, which basically acknowledges
correct termination of the invoked task. In the latter case, the MS correct termination of the invoked task. In the latter case, the MS
first sends back an interlocutory 202 message containing a 'Timeout' first sends back an interlocutory 202 message containing a 'Timeout'
value, which lets it enter a different state ('202' sent). While in value, which lets it enter a different state ('202' sent). While in
the new state, the MS keeps on performing the invoked task. If the the new state, the MS keeps on performing the invoked task. If the
task does not complete in the provided timeout, the server will task does not complete in the provided timeout, the server will
update the AS on the other side of the Control Channel by update the AS on the other side of the Control Channel by
periodically issuing 'REPORT update' messages; each such message has periodically issuing 'REPORT update' messages; each such message has
to be acknowledged by the AS (through a '200' response). Eventually, to be acknowledged by the AS (through a '200' response). Eventually,
when the MS is done with the required service, it sends to the AS a when the MS is done with the required service, it sends to the AS a
'REPORT terminate' message; the transaction is concluded when the AS 'REPORT terminate' message. The transaction is concluded when the AS
acknowledges receipt of the message. It is worth pointing out that acknowledges receipt of the message. It is worth pointing out that
the MS may send a 202 response after it determines that the request the MS may send a 202 response after it determines that the request
does not contain any errors that cannot be reported in a later REPORT does not contain any errors that cannot be reported in a later REPORT
terminate request instead. After the MS sends a 202 response, any terminate request instead. After the MS sends a 202 response, any
error that it (or the API) finds in the request is reported in the error that it (or the API) finds in the request is reported in the
final REPORT terminate request. Again, the behavior of the AS, as final REPORT terminate request. Again, the behavior of the AS, as
depicted in Figure 2, mirrors the above-described actions undertaken depicted in Figure 2, mirrors the above-described actions undertaken
at the MS side. The figures also show the cases in which at the MS side. The figures also show the cases in which
transactions cannot be successfully completed due to abnormal transactions cannot be successfully completed due to abnormal
conditions; such conditions always trigger the creation and conditions; such conditions always trigger the creation and
skipping to change at page 9, line 36 skipping to change at page 9, line 36
Figure 3: Event Notifications Figure 3: Event Notifications
5. Control Channel Establishment 5. Control Channel Establishment
As specified in [RFC6230], the preliminary step to any interaction As specified in [RFC6230], the preliminary step to any interaction
between an AS and an MS is the establishment of a Control Channel between an AS and an MS is the establishment of a Control Channel
between the two. As explained in the next subsection, this is between the two. As explained in the next subsection, this is
accomplished by means of a connection-oriented media (COMEDIA) accomplished by means of a connection-oriented media (COMEDIA)
[RFC4145] [RFC4572] negotiation. This negotiation allows a reliable [RFC4145] [RFC4572] negotiation. This negotiation allows a reliable
connection to be created between the AS and the MS: it is here that connection to be created between the AS and the MS. It is here that
the AS and the MS agree on the transport-level protocol to use (TCP / the AS and the MS agree on the transport-level protocol to use (TCP /
Stream Control Transmission Protocol (SCTP)) and whether any Stream Control Transmission Protocol (SCTP)) and whether any
application-level security is needed or not (e.g., TLS). For the application-level security is needed or not (e.g., TLS). For the
sake of simplicity, we assume that an unencrypted TCP connection is sake of simplicity, we assume that an unencrypted TCP connection is
negotiated between the two involved entities. Once they have negotiated between the two involved entities. Once they have
connected, a SYNC message sent by the AS to the MS consolidates the connected, a SYNC message sent by the AS to the MS consolidates the
Control Channel. An example of how a keep-alive message is triggered Control Channel. An example of how a keep-alive message is triggered
is also presented in the following paragraphs. For the sake of is also presented in the following paragraphs. For the sake of
completeness, this section also includes a couple of common mistakes completeness, this section also includes a couple of common mistakes
that can occur when dealing with the Control Channel establishment. that can occur when dealing with the Control Channel establishment.
skipping to change at page 16, line 44 skipping to change at page 16, line 44
5.4. Wrong Behavior 5.4. Wrong Behavior
This section will briefly address some types of behavior that could This section will briefly address some types of behavior that could
represent the most common mistakes when dealing with the represent the most common mistakes when dealing with the
establishment of a Control Channel between an AS and an MS. These establishment of a Control Channel between an AS and an MS. These
scenarios are obviously of interest, since they result in the AS and scenarios are obviously of interest, since they result in the AS and
the MS being unable to interact with each other. Specifically, these the MS being unable to interact with each other. Specifically, these
simple scenarios will be described: simple scenarios will be described:
1. an AS providing the MS with a wrong Dialog-ID in the initial 1. an AS providing the MS with a wrong Dialog-ID in the initial
SYNC; SYNC.
2. an AS sending a generic CONTROL message instead of SYNC as a 2. an AS sending a generic CONTROL message instead of SYNC as a
first transaction. first transaction.
The first scenario is depicted in Figure 8. The first scenario is depicted in Figure 8.
AS MS AS MS
. . . .
. . . .
| | | |
skipping to change at page 20, line 51 skipping to change at page 20, line 51
and the MS, and as such is not at all to be considered the mandatory and the MS, and as such is not at all to be considered the mandatory
way, nor best common practice, in the presented scenario. [RFC3725] way, nor best common practice, in the presented scenario. [RFC3725]
provides several different solutions and many details about how 3PCC provides several different solutions and many details about how 3PCC
can be realized, with pros and cons. It is also worth pointing out can be realized, with pros and cons. It is also worth pointing out
that the two INVITEs displayed in the figure are different SIP that the two INVITEs displayed in the figure are different SIP
dialogs. dialogs.
The UAC first places a call to a SIP URI for which the AS is The UAC first places a call to a SIP URI for which the AS is
responsible. The specific URI is not relevant to the examples, since responsible. The specific URI is not relevant to the examples, since
the application logic behind the mapping between a URI and the the application logic behind the mapping between a URI and the
service it provides is a matter that is important only to the AS: so, service it provides is a matter that is important only to the AS.
a generic 'sip:mediactrlDemo@as.example.com' is used in all the So, a generic 'sip:mediactrlDemo@as.example.com' is used in all the
examples, whereas the service this URI is associated with in the AS examples, whereas the service this URI is associated with in the AS
logic is mapped scenario by scenario to the case under examination. logic is mapped scenario by scenario to the case under examination.
The UAC INVITE is treated as envisaged in [RFC5567]. The INVITE is The UAC INVITE is treated as envisaged in [RFC5567]. The INVITE is
forwarded by the AS to the MS via a third party (e.g., the 3PCC forwarded by the AS to the MS via a third party (e.g., the 3PCC
approach), without the SDP provided by the UAC being touched, in approach), without the SDP provided by the UAC being touched, in
order to have the session fully negotiated by the MS according to its order to have the session fully negotiated by the MS according to its
description. The MS matches the UAC's offer with its own description. The MS matches the UAC's offer with its own
capabilities and provides its answer in a 200 OK. This answer is capabilities and provides its answer in a 200 OK. This answer is
then forwarded, again without the SDP contents being touched, by the then forwarded, again without the SDP contents being touched, by the
AS to the target UAC. This way, while the SIP signaling from the UAC AS to the target UAC. This way, while the SIP signaling from the UAC
skipping to change at page 25, line 43 skipping to change at page 25, line 43
[..] [..]
a=label:0132ca2 a=label:0132ca2
^^^^^^^ ^^^^^^^
These four identifiers allow the AS and MS to univocally and These four identifiers allow the AS and MS to univocally and
unambiguously address to each other the connections associated with unambiguously address to each other the connections associated with
the related UAC. Specifically: the related UAC. Specifically:
1. 10514b7f:6a900179, the concatenation of the 'From' and 'To' tags 1. 10514b7f:6a900179, the concatenation of the 'From' and 'To' tags
through a colon (':') token, addresses all the media connections through a colon (':') token, addresses all the media connections
between the MS and the UAC; between the MS and the UAC.
2. 10514b7f:6a900179 <-> 7eda834, the association of the previous 2. 10514b7f:6a900179 <-> 7eda834, the association of the previous
value with the label attribute, addresses only one of the media value with the label attribute, addresses only one of the media
connections of the UAC session (in this case, the audio stream); connections of the UAC session (in this case, the audio stream).
since, as will be made clearer in the example scenarios, the Since, as will be made clearer in the example scenarios, the
explicit identifiers in requests can only address 'from:tag' explicit identifiers in requests can only address 'from:tag'
connections, an additional mechanism will be required to have a connections, an additional mechanism will be required to have a
finer control of individual media streams (i.e., by means of the finer control of individual media streams (i.e., by means of the
<stream> element in package-level requests). <stream> element in package-level requests).
The mapping that the AS makes between the UACs<->AS and the AS<->MS The mapping that the AS makes between the UACs<->AS and the AS<->MS
SIP dialogs is out of scope for this document. We just assume that SIP dialogs is out of scope for this document. We just assume that
the AS knows how to address the right connection according to the the AS knows how to address the right connection according to the
related session it has with a UAC (e.g., to play an announcement to a related session it has with a UAC (e.g., to play an announcement to a
specific UAC); this is obviously very important, since the AS is specific UAC). This is obviously very important, since the AS is
responsible for all the business logic of the multimedia application responsible for all the business logic of the multimedia application
it provides. it provides.
6.1. Echo Test 6.1. Echo Test
The echo test is the simplest example scenario that can be achieved The echo test is the simplest example scenario that can be achieved
by means of an MS. It basically consists of a UAC directly or by means of an MS. It basically consists of a UAC directly or
indirectly "talking" to itself. A media perspective of such a indirectly "talking" to itself. A media perspective of such a
scenario is depicted in Figure 11. scenario is depicted in Figure 11.
skipping to change at page 27, line 6 skipping to change at page 27, line 6
o.....<<.......x | o.....<<.......x |
| | | |
+------+ +------+
Figure 12: Echo Test: UAC Media Leg Not Attached Figure 12: Echo Test: UAC Media Leg Not Attached
Starting from these considerations, two different approaches to the Starting from these considerations, two different approaches to the
Echo Test scenario are explored in this document: Echo Test scenario are explored in this document:
1. a Direct Echo Test approach, where the UAC directly talks to 1. a Direct Echo Test approach, where the UAC directly talks to
itself; itself.
2. a Recording-based Echo Test approach, where the UAC indirectly 2. a Recording-based Echo Test approach, where the UAC indirectly
talks to itself. talks to itself.
6.1.1. Direct Echo Test 6.1.1. Direct Echo Test
In the Direct Echo Test approach, the UAC is directly connected to In the Direct Echo Test approach, the UAC is directly connected to
itself. This means that, as depicted in Figure 13, each frame the MS itself. This means that, as depicted in Figure 13, each frame the MS
receives from the UAC is sent back to it in real time. receives from the UAC is sent back to it in real time.
skipping to change at page 28, line 9 skipping to change at page 28, line 9
| | | | | |
. . . . . .
. . . . . .
Figure 14: Self-Connection: Framework Transaction Figure 14: Self-Connection: Framework Transaction
The transaction steps have been numbered and are explained below: The transaction steps have been numbered and are explained below:
o The AS requests the joining of the connection to itself by sending o The AS requests the joining of the connection to itself by sending
to the MS a CONTROL request (1) that is specifically meant for the to the MS a CONTROL request (1) that is specifically meant for the
conferencing Control Package (msc-mixer/1.0); a <join> request is conferencing Control Package (msc-mixer/1.0). A <join> request is
used for this purpose, and since the connection must be attached used for this purpose, and since the connection must be attached
to itself, both id1 and id2 attributes are set to the same value, to itself, both id1 and id2 attributes are set to the same value,
i.e., the connectionid; i.e., the connectionid.
o The MS, having checked the validity of the request, enforces the o The MS, having checked the validity of the request, enforces the
joining of the connection to itself; this means that all the joining of the connection to itself. This means that all the
frames sent by the UAC are sent back to it; to report the result frames sent by the UAC are sent back to it. To report the result
of the operation, the MS sends a 200 OK (2) in reply to the AS, of the operation, the MS sends a 200 OK (2) in reply to the AS,
thus ending the transaction; the transaction ended successfully, thus ending the transaction. The transaction ended successfully,
as indicated by the body of the message (the 200 status code in as indicated by the body of the message (the 200 status code in
the <response> tag). the <response> tag).
The complete transaction -- that is, the full bodies of the exchanged The complete transaction -- that is, the full bodies of the exchanged
messages -- is provided in the following lines: messages -- is provided in the following lines:
1. AS -> MS (CFW CONTROL) 1. AS -> MS (CFW CONTROL)
------------------------- -------------------------
CFW 4fed9bf147e2 CONTROL CFW 4fed9bf147e2 CONTROL
Control-Package: msc-mixer/1.0 Control-Package: msc-mixer/1.0
skipping to change at page 29, line 31 skipping to change at page 29, line 31
Figure 15: Echo Test: Recording Involved Figure 15: Echo Test: Recording Involved
In the framework, this can be achieved by means of the IVR Control In the framework, this can be achieved by means of the IVR Control
Package [RFC6231], which is in charge of both the recording and the Package [RFC6231], which is in charge of both the recording and the
playout phases. However, the whole scenario cannot be accomplished playout phases. However, the whole scenario cannot be accomplished
in a single transaction; at least two steps, in fact, need to be in a single transaction; at least two steps, in fact, need to be
performed: performed:
1. First, a recording (preceded by an announcement, if requested) 1. First, a recording (preceded by an announcement, if requested)
must take place; must take place.
2. Then, a playout of the previously recorded media must occur. 2. Then, a playout of the previously recorded media must occur.
This means that two separate transactions need to be invoked. A This means that two separate transactions need to be invoked. A
sequence diagram of a potential multiple transaction is depicted in sequence diagram of a potential multiple transaction is depicted in
Figure 16: Figure 16:
UAC AS MS UAC AS MS
| | | | | |
| | A1. CONTROL (record for 10s) | | | A1. CONTROL (record for 10s) |
skipping to change at page 31, line 37 skipping to change at page 31, line 37
behavior. In fact, the 202+REPORT mechanism is assumed to be behavior. In fact, the 202+REPORT mechanism is assumed to be
involved only when the requested transaction is expected to take a involved only when the requested transaction is expected to take a
long time (e.g., retrieving a large media file for a prompt from an long time (e.g., retrieving a large media file for a prompt from an
external server). In this scenario, the transaction would be external server). In this scenario, the transaction would be
prepared in much less time and as a consequence would very likely be prepared in much less time and as a consequence would very likely be
completed within the context of a simple CONTROL+200 request/ completed within the context of a simple CONTROL+200 request/
response. The following scenarios will only involve 202+REPORTs when response. The following scenarios will only involve 202+REPORTs when
they are strictly necessary. they are strictly necessary.
Regarding the dialog itself, note how the AS-originated CONTROL Regarding the dialog itself, note how the AS-originated CONTROL
transactions are terminated as soon as the requested dialogs start: transactions are terminated as soon as the requested dialogs start.
as specified in [RFC6231], the MS uses a framework CONTROL message to As specified in [RFC6231], the MS uses a framework CONTROL message to
report the result of the dialog and how it has proceeded. The two report the result of the dialog and how it has proceeded. The two
transactions (the AS-generated CONTROL request and the MS-generated transactions (the AS-generated CONTROL request and the MS-generated
CONTROL event) are correlated by means of the associated dialog CONTROL event) are correlated by means of the associated dialog
identifier, as explained below. As before, the transaction steps identifier, as explained below. As before, the transaction steps
have been numbered. The two transactions are distinguished by the have been numbered. The two transactions are distinguished by the
preceding letter (A,B=recording, C,D=playout). preceding letter (A,B=recording, C,D=playout).
o The AS, as a first transaction, invokes a recording on the UAC o The AS, as a first transaction, invokes a recording on the UAC
connection by means of a CONTROL request (A1); the body is for the connection by means of a CONTROL request (A1). The body is for
IVR package (msc-ivr/1.0) and requests the start (<dialogstart>) the IVR package (msc-ivr/1.0) and requests the start
of a new recording context (<record>); the recording must be (<dialogstart>) of a new recording context (<record>). The
preceded by an announcement (<prompt>), must not last longer than recording must be preceded by an announcement (<prompt>), must not
10 s (maxtime), and cannot be interrupted by a DTMF tone last longer than 10 s (maxtime), and cannot be interrupted by a
(dtmfterm=false); this is only done once (the missing repeatCount DTMF tone (dtmfterm=false). This is only done once (the missing
attribute is 1 by default for a <dialog>), which means that if the repeatCount attribute is 1 by default for a <dialog>), which means
recording does not succeed the first time, the transaction must that if the recording does not succeed the first time, the
fail; a video recording is requested (considering that the transaction must fail. A video recording is requested
associated connection includes both audio and video and no (considering that the associated connection includes both audio
restriction is enforced on streams to record), which is to be fed and video and no restriction is enforced on streams to record),
by both of the negotiated media streams; a beep has to be played which is to be fed by both of the negotiated media streams. A
(beep=true) right before the recording starts, to notify the UAC; beep has to be played (beep=true) right before the recording
starts, to notify the UAC.
o As seen before, the MS sends a provisional 202 response to let the o As seen before, the MS sends a provisional 202 response to let the
AS know that the operation might need some time; AS know that the operation might need some time.
o In the meantime, the MS prepares the dialog (e.g., by retrieving o In the meantime, the MS prepares the dialog (e.g., by retrieving
the announcement file, for which an HTTP URL is provided, and by the announcement file, for which an HTTP URL is provided, and by
checking that the request is well formed) and if all is fine it checking that the request is well formed) and if all is fine it
starts it, notifying the AS with a new REPORT (A3) with a starts it, notifying the AS with a new REPORT (A3) with a
terminated status; as explained previously, interlocutory REPORT terminated status. As explained previously, interlocutory REPORT
messages with an update status would have been sent if the messages with an update status would have been sent if the
preparation took longer than the timeout provided in the 202 preparation took longer than the timeout provided in the 202
message (e.g., if retrieving the resource via HTTP took longer message (e.g., if retrieving the resource via HTTP took longer
than expected); once the dialog has been prepared and started, the than expected). Once the dialog has been prepared and started,
UAC connection is then passed to the IVR package, which first the UAC connection is then passed to the IVR package, which first
plays the announcement on the connection, followed by a beep, and plays the announcement on the connection, followed by a beep, and
then records all the incoming frames to a buffer; the MS also then records all the incoming frames to a buffer. The MS also
provides the AS with a unique dialog identifier (dialogid) that provides the AS with a unique dialog identifier (dialogid) that
will be used in all subsequent event notifications concerning the will be used in all subsequent event notifications concerning the
dialog it refers to; dialog it refers to.
o The AS acks the latest REPORT (A4), thus terminating this o The AS acks the latest REPORT (A4), thus terminating this
transaction, and waits for the results; transaction, and waits for the results.
o Once the recording is over, the MS prepares a notification CONTROL o Once the recording is over, the MS prepares a notification CONTROL
(B1); the <event> body is prepared with an explicit reference to (B1). The <event> body is prepared with an explicit reference to
the previously provided dialog identifier, in order to make the AS the previously provided dialog identifier, in order to make the AS
aware of the fact that the notification is related to that aware of the fact that the notification is related to that
specific dialog; the event body is then completed with the specific dialog. The event body is then completed with the
recording-related information (<recordinfo>), in this case the recording-related information (<recordinfo>), in this case the
path to the recorded file (here, an HTTP URL) that can be used by path to the recorded file (here, an HTTP URL) that can be used by
the AS for anything it needs; the payload also contains the AS for anything it needs. The payload also contains
information about the prompt (<promptinfo>), which is, however, information about the prompt (<promptinfo>), which is, however,
not relevant to the scenario; not relevant to the scenario.
o The AS concludes this first recording transaction by acking the o The AS concludes this first recording transaction by acking the
CONTROL event (B2). CONTROL event (B2).
Now that the first transaction has ended, the AS has the 10-s Now that the first transaction has ended, the AS has the 10-s
recording of the UAC talking and can let the UAC hear it by having recording of the UAC talking and can let the UAC hear it by having
the MS play it for the UAC as an announcement: the MS play it for the UAC as an announcement:
o In the second transaction, the AS invokes a playout on the UAC o In the second transaction, the AS invokes a playout on the UAC
connection by means of a new CONTROL request (C1); the body is connection by means of a new CONTROL request (C1). The body is
once again for the IVR package (msc-ivr/1.0), but this time it once again for the IVR package (msc-ivr/1.0), but this time it
requests the start (<dialogstart>) of a new announcement context requests the start (<dialogstart>) of a new announcement context
(<prompt>); the file to be played is the file that was recorded (<prompt>). The file to be played is the file that was recorded
before (<media>); before (<media>).
o Again, the usual provisional 202 (C2) takes place; o Again, the usual provisional 202 (C2) takes place.
o In the meantime, the MS prepares and starts the new dialog, and o In the meantime, the MS prepares and starts the new dialog, and
notifies the AS with a new REPORT (C3) with a terminated status: notifies the AS with a new REPORT (C3) with a terminated status.
the connection is then passed to the IVR package, which plays the The connection is then passed to the IVR package, which plays the
file on it; file on it.
o The AS acks the terminating REPORT (C4), now waiting for the o The AS acks the terminating REPORT (C4), now waiting for the
announcement to end; announcement to end.
o Once the playout is over, the MS sends a CONTROL event (D1) that o Once the playout is over, the MS sends a CONTROL event (D1) that
contains in its body (<promptinfo>) information about the just- contains in its body (<promptinfo>) information about the just-
concluded announcement; as before, the proper dialogid is used as concluded announcement. As before, the proper dialogid is used as
a reference to the correct dialog; a reference to the correct dialog.
o The AS concludes this second and last transaction by acking the o The AS concludes this second and last transaction by acking the
CONTROL event (D2). CONTROL event (D2).
As in the previous paragraph, the whole CFW interaction is provided As in the previous paragraph, the whole CFW interaction is provided
for a more in-depth evaluation of the protocol interaction. for a more in-depth evaluation of the protocol interaction.
A1. AS -> MS (CFW CONTROL, record) A1. AS -> MS (CFW CONTROL, record)
---------------------------------- ----------------------------------
CFW 796d83aa1ce4 CONTROL CFW 796d83aa1ce4 CONTROL
skipping to change at page 36, line 41 skipping to change at page 36, line 41
there are cases when the services provided by an MS might also prove there are cases when the services provided by an MS might also prove
useful for such phone calls. useful for such phone calls.
One of these cases is when the two UACs have no common supported One of these cases is when the two UACs have no common supported
codecs: having the two UACs directly negotiate the session would codecs: having the two UACs directly negotiate the session would
result in a session with no available media. Involving the MS as a result in a session with no available media. Involving the MS as a
transcoder would in this case still allow the two UACs to transcoder would in this case still allow the two UACs to
communicate. Another interesting case is when the AS (or any other communicate. Another interesting case is when the AS (or any other
entity on whose behalf the AS is working) is interested in entity on whose behalf the AS is working) is interested in
manipulating or monitoring the media session between the UACs, e.g., manipulating or monitoring the media session between the UACs, e.g.,
to record the conversation; a similar scenario will be dealt with in to record the conversation. A similar scenario will be dealt with in
Section 6.2.2. Section 6.2.2.
Before looking at how such a scenario might be accomplished by means Before looking at how such a scenario might be accomplished by means
of the Media Control Channel Framework, it is worth mentioning what of the Media Control Channel Framework, it is worth mentioning what
the SIP signaling involving all the interested parties might look the SIP signaling involving all the interested parties might look
like. In fact, in such a scenario, a 3PCC approach is absolutely like. In fact, in such a scenario, a 3PCC approach is absolutely
needed. An example is provided in Figure 17. Again, the presented needed. An example is provided in Figure 17. Again, the presented
example is not at all to be considered best common practice when 3PCC example is not at all to be considered best common practice when 3PCC
is needed in a MEDIACTRL-based framework. It is only described in is needed in a MEDIACTRL-based framework. It is only described in
order to help the reader more easily understand what the requirements order to help the reader more easily understand what the requirements
skipping to change at page 38, line 40 skipping to change at page 38, line 40
Of course, this is only one way to deal with the signaling and shall Of course, this is only one way to deal with the signaling and shall
not be considered an absolutely mandatory approach. not be considered an absolutely mandatory approach.
Once the negotiation is over, the two UACs are not in communication Once the negotiation is over, the two UACs are not in communication
yet. In fact, it's up to the AS now to actively trigger the MS to yet. In fact, it's up to the AS now to actively trigger the MS to
somehow attach their media streams to each other, by referring to the somehow attach their media streams to each other, by referring to the
connection identifiers associated with the UACs as explained connection identifiers associated with the UACs as explained
previously. This document presents two different approaches that previously. This document presents two different approaches that
might be followed, according to what needs to be accomplished. A might be followed, according to what needs to be accomplished. A
generic media perspective of the phone call scenario is depicted in generic media perspective of the phone call scenario is depicted in
Figure 18: the MS is basically in the media path between the two Figure 18. The MS is basically in the media path between the two
UACs. UACs.
+-------+ UAC1 (RTP) +--------+ UAC1 (RTP) +-------+ +-------+ UAC1 (RTP) +--------+ UAC1 (RTP) +-------+
| UAC |===================>| Media |===================>| UAC | | UAC |===================>| Media |===================>| UAC |
| 1 |<===================| Server |<===================| 2 | | 1 |<===================| Server |<===================| 2 |
+-------+ UAC2 (RTP) +--------+ UAC2 (RTP) +-------+ +-------+ UAC2 (RTP) +--------+ UAC2 (RTP) +-------+
Figure 18: Phone Call: Media Perspective Figure 18: Phone Call: Media Perspective
From the framework point of view, when the UACs' legs are not From the framework point of view, when the UACs' legs are not
skipping to change at page 39, line 24 skipping to change at page 39, line 24
| | | |
+--------------+ +--------------+
Figure 19: Phone Call: UAC Media Leg Not Attached Figure 19: Phone Call: UAC Media Leg Not Attached
6.2.1. Direct Connection 6.2.1. Direct Connection
The Direct Connection approach is the easiest, and a more The Direct Connection approach is the easiest, and a more
straightforward, approach to get the phone call between the two UACs straightforward, approach to get the phone call between the two UACs
to work. The idea is basically the same as that of the Direct Echo to work. The idea is basically the same as that of the Direct Echo
approach: a <join> directive is used to directly attach one UAC to approach. A <join> directive is used to directly attach one UAC to
the other, by exploiting the MS to only deal with the transcoding/ the other, by exploiting the MS to only deal with the transcoding/
adaption of the flowing frames, if needed. adaption of the flowing frames, if needed.
This approach is depicted in Figure 20. This approach is depicted in Figure 20.
MS MS
+--------------+ +--------------+
UAC 1 | | UAC 2 UAC 1 | | UAC 2
o----->>-------+~~~>>~~~+------->>-----o o----->>-------+~~~>>~~~+------->>-----o
o-----<<-------+~~~<<~~~+-------<<-----o o-----<<-------+~~~<<~~~+-------<<-----o
skipping to change at page 41, line 48 skipping to change at page 41, line 48
phone call but, as explained previously, might have some drawbacks phone call but, as explained previously, might have some drawbacks
whenever more advanced features are needed. For instance, one can't whenever more advanced features are needed. For instance, one can't
record the whole conversation -- only the single connections -- since record the whole conversation -- only the single connections -- since
no mixing is involved. Additionally, even the single task of playing no mixing is involved. Additionally, even the single task of playing
an announcement over the conversation could be complex, especially if an announcement over the conversation could be complex, especially if
the MS does not support implicit mixing over media connections. For the MS does not support implicit mixing over media connections. For
this reason, in more advanced cases a different approach might be this reason, in more advanced cases a different approach might be
taken, like the conference-based approach described in this section. taken, like the conference-based approach described in this section.
The idea is to use a mixing entity in the MS that acts as a bridge The idea is to use a mixing entity in the MS that acts as a bridge
between the two UACs: the presence of this entity allows more between the two UACs. The presence of this entity allows more
customization of what needs to be done with the conversation, like customization of what needs to be done with the conversation, like
the recording of the conversation that has been provided as an the recording of the conversation that has been provided as an
example. The approach is depicted in Figure 22. The mixing example. The approach is depicted in Figure 22. The mixing
functionality in the MS will be described in more detail in the functionality in the MS will be described in more detail in the
following section (which deals with many conference-related following section (which deals with many conference-related
scenarios), so only some hints will be provided here for basic scenarios), so only some hints will be provided here for basic
comprehension of the approach. comprehension of the approach.
MS MS
+---------------+ +---------------+
skipping to change at page 42, line 27 skipping to change at page 42, line 27
+-------:-------+ +-------:-------+
: :
+::::> (conversation.wav) +::::> (conversation.wav)
Figure 22: Phone Call: Conference-Based Approach Figure 22: Phone Call: Conference-Based Approach
To identify a single sample scenario, let's consider a phone call To identify a single sample scenario, let's consider a phone call
that the AS wants to record. that the AS wants to record.
Figure 23 shows how this could be accomplished in the Media Control Figure 23 shows how this could be accomplished in the Media Control
Channel Framework: this example, as usual, hides the previous Channel Framework. This example, as usual, hides the previous
interaction between the UACs and the AS and instead focuses on the interaction between the UACs and the AS and instead focuses on the
Control Channel operations and what follows. Control Channel operations and what follows.
UAC1 UAC2 AS MS UAC1 UAC2 AS MS
| | | | | | | |
| | | A1. CONTROL (create conference) | | | | A1. CONTROL (create conference) |
| | |++++++++++++++++++++++++++++++++>>| | | |++++++++++++++++++++++++++++++++>>|
| | | |--+ create | | | |--+ create
| | | | | conf and | | | | | conf and
| | | A2. 200 OK (conferenceid=Y) |<-+ its ID | | | A2. 200 OK (conferenceid=Y) |<-+ its ID
skipping to change at page 44, line 9 skipping to change at page 44, line 9
. . . . . . . .
Figure 23: Conference-Based Approach: Framework Transactions Figure 23: Conference-Based Approach: Framework Transactions
The AS uses two different packages to accomplish this scenario: the The AS uses two different packages to accomplish this scenario: the
Mixer package (to create the mixing entity and join the UACs) and the Mixer package (to create the mixing entity and join the UACs) and the
IVR package (to record what happens in the conference). The IVR package (to record what happens in the conference). The
framework transaction steps can be described as follows: framework transaction steps can be described as follows:
o First of all, the AS creates a new hidden conference by means of a o First of all, the AS creates a new hidden conference by means of a
<createconference> request (A1); this conference is properly <createconference> request (A1). This conference is properly
configured according to the use it is assigned to; in fact, since configured according to the use it is assigned to. In fact, since
only two participants will be joined to it, both only two participants will be joined to it, both
'reserved-talkers' and 'reserved-listeners' are set to 2, just as 'reserved-talkers' and 'reserved-listeners' are set to 2, just as
the 'n' value for the N-best audio mixing algorithm; the video the 'n' value for the N-best audio mixing algorithm. The video
layout is also set accordingly (<single-view>/<dual-view>); layout is also set accordingly (<single-view>/<dual-view>).
o The MS sends notification of the successful creation of the new o The MS sends notification of the successful creation of the new
conference in a 200 framework message (A2); the identifier conference in a 200 framework message (A2). The identifier
assigned to the conference, which will be used in subsequent assigned to the conference, which will be used in subsequent
requests addressed to it, is 6013f1e; requests addressed to it, is 6013f1e.
o The AS requests a new recording for the newly created conference; o The AS requests a new recording for the newly created conference.
to do so, it places a proper request to the IVR package (B1); the To do so, it places a proper request to the IVR package (B1). The
AS is interested in a video recording (type=video/mpeg), which AS is interested in a video recording (type=video/mpeg), which
must not last longer than 3 hours (maxtime=10800s), after which must not last longer than 3 hours (maxtime=10800s), after which
the recording must end; additionally, no beep must be played on the recording must end. Additionally, no beep must be played on
the conference (beep=false), and the recording must start the conference (beep=false), and the recording must start
immediately whether or not any audio activity has been reported immediately whether or not any audio activity has been reported
(vadinitial=false is the default value for <record>); (vadinitial=false is the default value for <record>).
o The transaction is handled by the MS, and when the dialog has been o The transaction is handled by the MS, and when the dialog has been
successfully started, a 200 OK is issued to the AS (B2); the successfully started, a 200 OK is issued to the AS (B2). The
message contains the dialogid associated with the dialog message contains the dialogid associated with the dialog
(00b29fb), which the AS must refer to for later notifications; (00b29fb), which the AS must refer to for later notifications.
o At this point, the AS attaches both UACs to the conference with o At this point, the AS attaches both UACs to the conference with
two separate <join> directives (C1/D1); when the MS confirms the two separate <join> directives (C1/D1). When the MS confirms the
success of both operations (C2/D2), the two UACs are actually in success of both operations (C2/D2), the two UACs are actually in
contact with each other (even though indirectly, since a hidden contact with each other (even though indirectly, since a hidden
conference they're unaware of is on their path), and their media conference they're unaware of is on their path), and their media
contribution is recorded. contribution is recorded.
A1. AS -> MS (CFW CONTROL, createconference) A1. AS -> MS (CFW CONTROL, createconference)
-------------------------------------------- --------------------------------------------
CFW 238e1f2946e8 CONTROL CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml Content-Type: application/msc-mixer+xml
skipping to change at page 47, line 14 skipping to change at page 47, line 14
CFW 140e0f763352 200 CFW 140e0f763352 200
Timeout: 10 Timeout: 10
Content-Type: application/msc-mixer+xml Content-Type: application/msc-mixer+xml
Content-Length: 125 Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/> <response status="200" reason="Join successful"/>
</mscmixer> </mscmixer>
The recording of the conversation can subsequently be accessed by the The recording of the conversation can subsequently be accessed by the
AS by waiting for an event notification from the MS: this event, AS by waiting for an event notification from the MS. This event,
which will be associated with the previously started recording which will be associated with the previously started recording
dialog, will contain the URI of the recorded file. Such an event may dialog, will contain the URI of the recorded file. Such an event may
be triggered by either a natural completion of the dialog (e.g., the be triggered by either a natural completion of the dialog (e.g., the
dialog has reached its programmed 3 hours) or any interruption of the dialog has reached its programmed 3 hours) or any interruption of the
dialog itself (e.g., the AS actively requests that the recording be dialog itself (e.g., the AS actively requests that the recording be
interrupted, since the call between the UACs ended). interrupted, since the call between the UACs ended).
6.2.3. Recording a Conversation 6.2.3. Recording a Conversation
The previous section described how to take advantage of the The previous section described how to take advantage of the
skipping to change at page 47, line 44 skipping to change at page 47, line 44
between two UACs, the use of just the <join> directive without a between two UACs, the use of just the <join> directive without a
mixer forces the AS to just rely on separate recording commands. mixer forces the AS to just rely on separate recording commands.
That is, the AS can only instruct the MS to separately record the That is, the AS can only instruct the MS to separately record the
media flowing on each media leg: a recording for all the data coming media flowing on each media leg: a recording for all the data coming
from UAC1, and a different recording for all the data coming from from UAC1, and a different recording for all the data coming from
UAC2. If someone subsequently wants to access the whole UAC2. If someone subsequently wants to access the whole
conversation, the AS may take at least two different approaches: conversation, the AS may take at least two different approaches:
1. It may mix the two recordings itself (e.g., by delegating it to 1. It may mix the two recordings itself (e.g., by delegating it to
an offline mixing entity) in order to obtain a single file an offline mixing entity) in order to obtain a single file
containing the combination of the two recordings; this way, a containing the combination of the two recordings. This way, a
simple playout as described in Section 6.1.2 would suffice; simple playout as described in Section 6.1.2 would suffice.
2. Alternatively, it may take advantage of the mixing functionality 2. Alternatively, it may take advantage of the mixing functionality
provided by the MS itself; one way to do this is to create a provided by the MS itself. One way to do this is to create a
hidden conference on the MS, attach the UAC as a passive hidden conference on the MS, attach the UAC as a passive
participant to it, and play the separate recordings on the participant to it, and play the separate recordings on the
conference as announcements; this way, the UAC accessing the conference as announcements. This way, the UAC accessing the
recording would experience both of the recordings at the same recording would experience both of the recordings at the same
time. time.
The second approach is considered in this section. The framework The second approach is considered in this section. The framework
transaction as described in Figure 24 assumes that a recording has transaction as described in Figure 24 assumes that a recording has
already been requested for both UAC1 and UAC2, that the phone call already been requested for both UAC1 and UAC2, that the phone call
has ended, and that the AS has successfully received the URIs to both has ended, and that the AS has successfully received the URIs to both
of the recordings from the MS. Such steps are not described again, of the recordings from the MS. Such steps are not described again,
since they would be quite similar to the steps described in since they would be quite similar to the steps described in
Section 6.1.2. As mentioned previously, the idea is to use a Section 6.1.2. As mentioned previously, the idea is to use a
properly constructed hidden conference to mix the two separate properly constructed hidden conference to mix the two separate
recordings on the fly and present them to the UAC. It is, of course, recordings on the fly and present them to the UAC. It is, of course,
up to the AS to subsequently unjoin the user from the conference and up to the AS to subsequently unjoin the user from the conference and
destroy the conference itself once the playout of the recordings ends destroy the conference itself once the playout of the recordings ends
for any reason. for any reason.
UAC3 AS MS UAC3 AS MS
| | | | | |
| (UAC1 and UAC2 have previously been recorded: the AS has | | (UAC1 and UAC2 have previously been recorded; the AS has |
| the two different recordings available for playout.) | | the two different recordings available for playout.) |
| | | | | |
| | A1. CONTROL (create conference) | | | A1. CONTROL (create conference) |
| |++++++++++++++++++++++++++++++++>>| | |++++++++++++++++++++++++++++++++>>|
| | |--+ create | | |--+ create
| | | | conf & | | | | conf &
| | A2. 200 OK (conferenceid=Y) |<-+ its ID | | A2. 200 OK (conferenceid=Y) |<-+ its ID
| |<<++++++++++++++++++++++++++++++++| | |<<++++++++++++++++++++++++++++++++|
| | | | | |
| | B1. CONTROL (join UAC3 & confY) | | | B1. CONTROL (join UAC3 & confY) |
skipping to change at page 49, line 37 skipping to change at page 49, line 37
The diagram above assumes that a recording of both of the channels The diagram above assumes that a recording of both of the channels
(UAC1 and UAC2) has already taken place. Later, when we desire to (UAC1 and UAC2) has already taken place. Later, when we desire to
play the whole conversation to a new user, UAC3, the AS may take care play the whole conversation to a new user, UAC3, the AS may take care
of the presented transactions. The framework transaction steps are of the presented transactions. The framework transaction steps are
only apparently more complicated than those presented so far. The only apparently more complicated than those presented so far. The
only difference, in fact, is that transactions C and D are only difference, in fact, is that transactions C and D are
concurrent, since the recordings must be played together. concurrent, since the recordings must be played together.
o First of all, the AS creates a new conference to act as a mixing o First of all, the AS creates a new conference to act as a mixing
entity (A1); the settings for the conference are chosen according entity (A1). The settings for the conference are chosen according
to the use case, e.g., the video layout, which is fixed to <dual- to the use case, e.g., the video layout, which is fixed to <dual-
view>, and the switching type to <controller>; when the conference view>, and the switching type to <controller>. When the
has been successfully created (A2), the AS takes note of the conference has been successfully created (A2), the AS takes note
conference identifier; of the conference identifier.
o At this point, UAC3 is attached to the conference as a passive o At this point, UAC3 is attached to the conference as a passive
user (B1); there would be no point in letting the user contribute user (B1). There would be no point in letting the user contribute
to the conference mix, since he will only need to watch a to the conference mix, since he will only need to watch a
recording; in order to specify his passive status, both the audio recording. In order to specify his passive status, both the audio
and video streams for the user are set to 'recvonly'; if the and video streams for the user are set to 'recvonly'. If the
transaction succeeds, the MS notifies the AS (B2); transaction succeeds, the MS notifies the AS (B2).
o Once the conference has been created and UAC3 has been attached to o Once the conference has been created and UAC3 has been attached to
it, the AS can request the playout of the recordings; in order to it, the AS can request the playout of the recordings; in order to
do so, it requests two concurrent <prompt> directives (C1 and D1), do so, it requests two concurrent <prompt> directives (C1 and D1),
addressing the recording of UAC1 (REC1) and UAC2 (REC2), addressing the recording of UAC1 (REC1) and UAC2 (REC2),
respectively; both of the prompts must be played on the previously respectively. Both of the prompts must be played on the
created conference and not to UAC3 directly, as can be deduced previously created conference and not to UAC3 directly, as can be
from the 'conferenceid' attribute of the <dialog> element; deduced from the 'conferenceid' attribute of the <dialog> element.
o The transactions "live their lives" exactly as explained for o The transactions "live their lives" exactly as explained for
previous <prompt> examples; the originating transactions are first previous <prompt> examples. The originating transactions are
prepared and started (C2, D2), and then, as soon as the playout first prepared and started (C2, D2), and then, as soon as the
ends, a related CONTROL message is triggered by the MS (E1, F1); playout ends, a related CONTROL message is triggered by the MS
this notification may contain a <promptinfo> element with (E1, F1). This notification may contain a <promptinfo> element
information about how the playout proceeded (e.g., whether the with information about how the playout proceeded (e.g., whether
playout completed normally or was interrupted by a DTMF tone, the playout completed normally or was interrupted by a DTMF tone,
etc.). etc.).
A1. AS -> MS (CFW CONTROL, createconference) A1. AS -> MS (CFW CONTROL, createconference)
-------------------------------------------- --------------------------------------------
CFW 506e039f65bd CONTROL CFW 506e039f65bd CONTROL
Control-Package: msc-mixer/1.0 Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml Content-Type: application/msc-mixer+xml
Content-Length: 312 Content-Length: 312
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
skipping to change at page 55, line 10 skipping to change at page 55, line 10
oo oo
UAC C UAC C
Figure 26: Conference: UAC Legs Not Attached Figure 26: Conference: UAC Legs Not Attached
The next subsections will cover several typical scenarios involving The next subsections will cover several typical scenarios involving
mixing and conferencing as a whole, specifically: mixing and conferencing as a whole, specifically:
1. Simple Bridging scenario, which is a very basic (i.e., no 1. Simple Bridging scenario, which is a very basic (i.e., no
"special effects"; just mixing involved) conference involving one "special effects"; just mixing involved) conference involving one
or more participants; or more participants.
2. Rich Conference scenario, which enriches the Simple Bridging 2. Rich Conference scenario, which enriches the Simple Bridging
scenario by adding additional features typically found in scenario by adding additional features typically found in
conferencing systems (e.g., DTMF collection for PIN-based conferencing systems (e.g., DTMF collection for PIN-based
conference access, private and global announcements, recordings, conference access, private and global announcements, recordings,
and so on); and so on).
3. Coaching scenario, which is a more complex scenario that involves 3. Coaching scenario, which is a more complex scenario that involves
per-user mixing (customers, agents, and coaches don't all get the per-user mixing (customers, agents, and coaches don't all get the
same mixes); same mixes).
4. Sidebars scenario, which adds more complexity to the previous 4. Sidebars scenario, which adds more complexity to the previous
conferencing scenarios by involving sidebars (i.e., separate conferencing scenarios by involving sidebars (i.e., separate
conference instances that only exist within the context of a conference instances that only exist within the context of a
parent conference instance) and the custom media delivery that parent conference instance) and the custom media delivery that
follows; follows.
5. Floor Control scenario, which provides some guidance on how floor 5. Floor Control scenario, which provides some guidance on how floor
control could be involved in a MEDIACTRL-based media conference. control could be involved in a MEDIACTRL-based media conference.
All of the above-mentioned scenarios depend on the availability of a All of the above-mentioned scenarios depend on the availability of a
mixing entity. Such an entity is provided in the Media Control mixing entity. Such an entity is provided in the Media Control
Channel Framework by the conferencing package. Besides allowing for Channel Framework by the conferencing package. Besides allowing for
the interconnection of media sources as seen in the Direct Echo Test the interconnection of media sources as seen in the Direct Echo Test
section, this package enables the creation of abstract connections section, this package enables the creation of abstract connections
that can be joined to multiple connections: these abstract that can be joined to multiple connections. These abstract
connections, called conferences, mix the contribution of each connections, called conferences, mix the contribution of each
attached connection and feed them accordingly (e.g., a connection attached connection and feed them accordingly (e.g., a connection
with a 'sendrecv' property would be able to contribute to the mix and with a 'sendrecv' property would be able to contribute to the mix and
listen to it, while a connection with a 'recvonly' property would listen to it, while a connection with a 'recvonly' property would
only be able to listen to the overall mix but not actively contribute only be able to listen to the overall mix but not actively contribute
to it). to it).
That said, each of the above-mentioned scenarios will start more or 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 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 more than one, as needed in some cases) to be subsequently referred
skipping to change at page 56, line 29 skipping to change at page 56, line 29
Figure 27: Conference: Framework Transactions Figure 27: Conference: Framework Transactions
The call flow is quite straightforward and can typically be The call flow is quite straightforward and can typically be
summarized in the following steps: summarized in the following steps:
o The AS invokes the creation of a new conference instance by means o The AS invokes the creation of a new conference instance by means
of a CONTROL request (1); this request is addressed to the of a CONTROL request (1); this request is addressed to the
conferencing package (msc-mixer/1.0) and contains in the body the conferencing package (msc-mixer/1.0) and contains in the body the
directive (<createconference>) with all the desired settings for directive (<createconference>) with all the desired settings for
the new conference instance; in the example below, the mixing the new conference instance. In the example below, the mixing
policy is to mix the five ('reserved-talkers') loudest speakers policy is to mix the five ('reserved-talkers') loudest speakers
(nbest), while ten listeners at maximum are allowed; video (nbest), while ten listeners at maximum are allowed. Video
settings are configured, including the mechanism used to select settings are configured, including the mechanism used to select
active video sources (<controller>, meaning the AS will explicitly active video sources (<controller>, meaning the AS will explicitly
instruct the MS about it) and details about the video layouts to instruct the MS about it) and details about the video layouts to
make available; in this example, the AS is instructing the MS 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, 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 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 are active, and to use a <multiple-5x1> layout whenever the number
of sources is at least five; finally, the AS also subscribes to of sources is at least five. Finally, the AS also subscribes to
the "active-talkers" event, which means it wants to be informed the "active-talkers" event, which means it wants to be informed
(at a rate of 4 seconds) whenever an active participant is (at a rate of 4 seconds) whenever an active participant is
speaking; speaking.
o The MS creates the conference instance, assigns a unique o The MS creates the conference instance, assigns a unique
identifier to it (6146dd5), and completes the transaction with a identifier to it (6146dd5), and completes the transaction with a
200 response (2); 200 response (2).
o At this point, the requested conference instance is active and 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 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. the use of this identifier in its application logic.
1. AS -> MS (CFW CONTROL) 1. AS -> MS (CFW CONTROL)
------------------------- -------------------------
CFW 3032e5fb79a1 CONTROL CFW 3032e5fb79a1 CONTROL
Control-Package: msc-mixer/1.0 Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml Content-Type: application/msc-mixer+xml
Content-Length: 489 Content-Length: 489
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
skipping to change at page 58, line 48 skipping to change at page 58, line 48
Figure 28: Conference: Simple Bridging Figure 28: Conference: Simple Bridging
In the framework, the first step is obviously to create a new In the framework, the first step is obviously to create a new
conference instance as seen in the introductory section (Figure 27). conference instance as seen in the introductory section (Figure 27).
Assuming that a conference instance has already been created, Assuming that a conference instance has already been created,
bridging participants to it is quite straightforward and can be bridging participants to it is quite straightforward and can be
accomplished as seen in the Direct Echo Test scenario. The only accomplished as seen in the Direct Echo Test scenario. The only
difference here is that each participant is not directly connected to difference here is that each participant is not directly connected to
itself (Direct Echo) or another UAC (Direct Connection) but to the itself (Direct Echo) or another UAC (Direct Connection) but to the
bridge instead. Figure 29 shows the example of two different UACs bridge instead. Figure 29 shows the example of two different UACs
joining the same conference: the example, as usual, hides the joining the same conference. The example, as usual, hides the
previous interaction between each of the two UACs and the AS, and 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 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. participants to the bridge so that they can interact in a conference.
Please note also that to make the diagram more readable, two Please note also that to make the diagram more readable, two
different identifiers (UAC1 and UAC2) are used in place of the different identifiers (UAC1 and UAC2) are used in place of the
identifiers previously employed to introduce the scenario (UAC A, B, identifiers previously employed to introduce the scenario (UAC A, B,
C). C).
UAC1 UAC2 AS MS UAC1 UAC2 AS MS
skipping to change at page 61, line 8 skipping to change at page 61, line 8
Content-Type: application/msc-mixer+xml Content-Type: application/msc-mixer+xml
Content-Length: 125 Content-Length: 125
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="Join successful"/> <response status="200" reason="Join successful"/>
</mscmixer> </mscmixer>
Once one or more participants have been attached to the bridge, their Once one or more participants have been attached to the bridge, their
connections and how their media are handled by the bridge can be connections and how their media are handled by the bridge can be
dynamically manipulated by means of another directive, called dynamically manipulated by means of another directive, called
<modifyjoin>: a typical use case for this directive is the change of <modifyjoin>. A typical use case for this directive is the change of
direction of an existing media (e.g., a previously speaking direction of an existing media (e.g., a previously speaking
participant is muted, which means its media direction changes from participant is muted, which means its media direction changes from
'sendrecv' to 'recvonly'). Figure 30 shows how a framework 'sendrecv' to 'recvonly'). Figure 30 shows how a framework
transaction requesting such a directive might appear. transaction requesting such a directive might appear.
UAC1 UAC2 AS MS UAC1 UAC2 AS MS
| | | | | | | |
| | | 1. CONTROL (modifyjoin UAC1) | | | | 1. CONTROL (modifyjoin UAC1) |
| | |++++++++++++++++++++++++++++++++>>| | | |++++++++++++++++++++++++++++++++>>|
| | | |--+ modify | | | |--+ modify
skipping to change at page 63, line 36 skipping to change at page 63, line 36
UAC C UAC C
Figure 31: Conference: Rich Conference Scenario Figure 31: Conference: Rich Conference Scenario
To identify a single sample scenario, let's consider this sequence To identify a single sample scenario, let's consider this sequence
for a participant joining a conference (which again we assume has for a participant joining a conference (which again we assume has
already been created): already been created):
1. The UAC as usual INVITEs a URI associated with a conference, and 1. The UAC as usual INVITEs a URI associated with a conference, and
the AS follows the previously explained procedure to have the UAC the AS follows the previously explained procedure to have the UAC
negotiate a new media session with the MS; negotiate a new media session with the MS.
2. The UAC is presented with an IVR menu, in which it is requested 2. The UAC is presented with an IVR menu, in which it is requested
to input a PIN code to access the conference; 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 3. If the PIN is correct, the UAC is asked to state its name so that
it can be recorded; it can be recorded.
4. The UAC is attached to the conference, and the previously 4. The UAC is attached to the conference, and the previously
recorded name is announced globally to the conference to recorded name is announced globally to the conference to
advertise its arrival. advertise its arrival.
Figure 32 shows a single UAC joining a conference: the example, as Figure 32 shows a single UAC joining a conference. The example, as
usual, hides the previous interaction between the UAC and the AS, and usual, hides the previous interaction between the UAC and the AS, and
instead focuses on what the AS does to actually interact with the instead focuses on what the AS does to actually interact with the
participant and join it to the conference bridge. participant and join it to the conference bridge.
UAC AS MS UAC AS MS
| | | | | |
| | A1. CONTROL (request DTMF PIN) | | | A1. CONTROL (request DTMF PIN) |
| |++++++++++++++++++++++++++++++++>>| | |++++++++++++++++++++++++++++++++>>|
| | |--+ start | | |--+ start
| | | | the | | | | the
skipping to change at page 65, line 38 skipping to change at page 65, line 38
Figure 32: Rich Conference Scenario: Framework Transactions Figure 32: Rich Conference Scenario: Framework Transactions
As can be deduced from the sequence diagram above, the AS, in its As can be deduced from the sequence diagram above, the AS, in its
business logic, correlates the results of different transactions, business logic, correlates the results of different transactions,
addressed to different packages, to implement a conferencing scenario addressed to different packages, to implement a conferencing scenario
more complex than the Simple Bridging scenario previously described. more complex than the Simple Bridging scenario previously described.
The framework transaction steps are as follows: The framework transaction steps are as follows:
o Since this is a private conference, the UAC is to be presented 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 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 so, the AS instructs the MS (A1) to collect a series of DTMF
digits from the specified UAC (connectionid=UAC); the request digits from the specified UAC (connectionid=UAC). The request
includes both a voice message (<prompt>) and the described digit includes both a voice message (<prompt>) and the described digit
collection context (<collect>); the PIN is assumed to be a 4-digit collection context (<collect>). The PIN is assumed to be a
number, and so the MS has to collect 4 digits maximum 4-digit number, and so the MS has to collect 4 digits maximum
(maxdigits=4); the DTMF digit buffer must be cleared before (maxdigits=4). The DTMF digit buffer must be cleared before
collecting (cleardigitbuffer=true), and the UAC can use the star collecting (cleardigitbuffer=true), and the UAC can use the star
key to restart the collection (escapekey=*), e.g., if the UAC is 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; 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 o The transaction goes on as usual (A2), with the transaction being
handled and notification of the dialog start being sent in a 200 handled and notification of the dialog start being sent in a 200
OK; after that, the UAC is actually presented with the voice OK. After that, the UAC is actually presented with the voice
message and is subsequently requested to input the required PIN message and is subsequently requested to input the required PIN
number; number.
o We assume that the UAC typed the correct PIN number (1234), which 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 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 CONTROL event (B1). The AS correlates this event to the
started dialog by checking the referenced dialogid (06d1bac) and previously started dialog by checking the referenced dialogid
acks the event (B2); it then extracts the information it needs (06d1bac) and acks the event (B2). It then extracts the
from the event (in this case, the digits provided by the MS) from information it needs from the event (in this case, the digits
the <controlinfo> container (dtmf=1234) and verifies that it is provided by the MS) from the <controlinfo> container (dtmf=1234)
correct; and verifies that it is correct.
o Since the PIN is correct, the AS can proceed to the next step, 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 i.e., asking the UAC to state his name, in order to subsequently
play the recording on the conference to report the new play the recording on the conference to report the new
participant; again, this is done with a request to the IVR package participant. Again, this is done with a request to the IVR
(C1); the AS instructs the MS to play a voice message ("state your package (C1). The AS instructs the MS to play a voice message
name after the beep"), to be followed by a recording of only the ("state your name after the beep"), to be followed by a recording
audio from the UAC (in stream, media=audio/sendonly, while of only the audio from the UAC (in stream, media=audio/sendonly,
media=video/inactive); a beep must be played right before the while media=video/inactive). A beep must be played right before
recording starts (beep=true), and the recording must only last the recording starts (beep=true), and the recording must only last
3 seconds (maxtime=3s), since it is only needed as a brief 3 seconds (maxtime=3s), since it is only needed as a brief
announcement; announcement.
o Without delving again into the details of a recording-related o Without delving again into the details of a recording-related
transaction (C2), the AS finally gets the URI of the requested transaction (C2), the AS finally gets the URI of the requested
recording (D1, acked in D2); recording (D1, acked in D2).
o At this point, the AS attaches the UAC (id1) to the conference o At this point, the AS attaches the UAC (id1) to the conference
(id2), just as explained for the Simple Bridging scenario (E1/E2); (id2), just as explained for the Simple Bridging scenario (E1/E2).
o Finally, to notify the other participants that a new participant o Finally, to notify the other participants that a new participant
has arrived, the AS requests a global announcement on the has arrived, the AS requests a global announcement on the
conference; this is a simple <prompt> request to the IVR package conference. This is a simple <prompt> request to the IVR package
(F1), as explained in previous sections (e.g., Section 6.1.2, (F1), as explained in previous sections (e.g., Section 6.1.2,
among others), but with a slight difference: the target of the among others), but with a slight difference: the target of the
prompt is not a connectionid (a media connection) but the prompt is not a connectionid (a media connection) but the
conference itself (conferenceid=6146dd5); as a result of this conference itself (conferenceid=6146dd5). As a result of this
transaction, the announcement would be played on all the media transaction, the announcement would be played on all the media
connections attached to the conference that are allowed to receive connections attached to the conference that are allowed to receive
media from it; the AS specifically requests that two media files media from it. The AS specifically requests that two media files
be played: be played:
1. the media file containing the recorded name of the new user as 1. the media file containing the recorded name of the new user as
retrieved in D1 ("Simon..."); retrieved in D1 ("Simon...").
2. a pre-recorded media file explaining what happened ("... has 2. a pre-recorded media file explaining what happened ("... has
joined the conference"); joined the conference").
The transaction then follows its usual flow (F2), and the event The transaction then follows its usual flow (F2), and the event
that sends notification regarding the end of the announcement (G1, that sends notification regarding the end of the announcement (G1,
acked in G2) concludes the scenario. acked in G2) concludes the scenario.
A1. AS -> MS (CFW CONTROL, collect) A1. AS -> MS (CFW CONTROL, collect)
----------------------------------- -----------------------------------
CFW 50e56b8d65f9 CONTROL CFW 50e56b8d65f9 CONTROL
Control-Package: msc-ivr/1.0 Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml Content-Type: application/msc-ivr+xml
skipping to change at page 71, line 28 skipping to change at page 71, line 28
what to say. This scenario is also described in [RFC4597]. what to say. This scenario is also described in [RFC4597].
As can be deduced from the scenario description, per-user policies As can be deduced from the scenario description, per-user policies
for media mixing and delivery, i.e., who can hear what, are very 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 important. The MS must make sure that only the agent can hear the
coach's suggestions. Since this is basically a multiparty call coach's suggestions. Since this is basically a multiparty call
(despite what the customer might be thinking), a mixing entity is (despite what the customer might be thinking), a mixing entity is
needed in order to accomplish the scenario requirements. To needed in order to accomplish the scenario requirements. To
summarize: summarize:
o The customer (A) must only hear what the agent (B) says; 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 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 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. suggestions and also be aware of the whole conversation.
From the media and framework perspective, such a scenario can be seen From the media and framework perspective, such a scenario can be seen
as depicted in Figure 33. as depicted in Figure 33.
************** +-------+ ************** +-------+
* A=Customer * | UAC | * A=Customer * | UAC |
* B=Agent * | C | * B=Agent * | C |
skipping to change at page 72, line 33 skipping to change at page 72, line 33
.| .|
.| .|
oo oo
UAC C UAC C
Figure 34: Coaching Scenario: UAC Legs Not Attached Figure 34: Coaching Scenario: UAC Legs Not Attached
By contrast, what the scenario should look like is depicted in By contrast, what the scenario should look like is depicted in
Figure 35. The customer receives media directly from the agent Figure 35. The customer receives media directly from the agent
('recvonly'), while all of the three involved participants contribute ('recvonly'), while all of the three involved participants contribute
to a hidden conference: of course, the customer is not allowed to to a hidden conference. Of course, the customer is not allowed to
receive the mixed flows from the conference ('sendonly'), unlike the receive the mixed flows from the conference ('sendonly'), unlike the
agent and the coach, who must both be aware of the whole conversation agent and the coach, who must both be aware of the whole conversation
('sendrecv'). ('sendrecv').
MS MS
+---------------------------+ +---------------------------+
| | | |
UAC A | | UAC B UAC A | | UAC B
o-----<<-------+----<<----+----<<----+-------<<-----o o-----<<-------+----<<----+----<<----+-------<<-----o
o----->>-------+ | +------->>-----o o----->>-------+ | +------->>-----o
skipping to change at page 73, line 31 skipping to change at page 73, line 31
oo oo
UAC C UAC C
Figure 35: Coaching Scenario: UAC Legs Mixed and Attached Figure 35: Coaching Scenario: UAC Legs Mixed and Attached
In the framework, this can be achieved by means of the Mixer Control In the framework, this can be achieved by means of the Mixer Control
Package, which, as demonstrated in the previous conferencing Package, which, as demonstrated in the previous conferencing
examples, can be exploited whenever mixing and joining entities are examples, can be exploited whenever mixing and joining entities are
needed. The needed steps can be summarized in the following list: needed. The needed steps can be summarized in the following list:
1. First of all, a hidden conference is created; 1. First of all, a hidden conference is created.
2. Then, the three participants are all attached to it, each with a 2. Then, the three participants are all attached to it, each with a
custom mixing policy, specifically: custom mixing policy, specifically:
* the customer (A) as 'sendonly'; * the customer (A) as 'sendonly'.
* the agent (B) as 'sendrecv'; * the agent (B) as 'sendrecv'.
* the coach (C) as 'sendrecv' and with a gain of -3 dB to halve * 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 the volume of its own contribution (so that the agent actually
hears the customer at a louder volume and hears the coach hears the customer at a louder volume and hears the coach
whispering); whispering).
3. Finally, the customer is joined to the agent as a passive 3. Finally, the customer is joined to the agent as a passive
receiver ('recvonly'). receiver ('recvonly').
A diagram of such a sequence of transactions is depicted in A diagram of such a sequence of transactions is depicted in
Figure 36: Figure 36:
A B C AS MS A B C AS MS
| | | | | | | | | |
| | | | A1. CONTROL (create conference) | | | | | A1. CONTROL (create conference) |
skipping to change at page 75, line 14 skipping to change at page 75, line 14
|<<######################################################| |<<######################################################|
| Finally, Customer (A) is joined (recvonly) to Agent (B)| | Finally, Customer (A) is joined (recvonly) to Agent (B)|
|<<######################################################| |<<######################################################|
| | | | | | | | | |
. . . . . . . . . .
. . . . . . . . . .
Figure 36: Coaching Scenario: Framework Transactions Figure 36: Coaching Scenario: Framework Transactions
o First of all, the AS creates a new hidden conference by means of a o First of all, the AS creates a new hidden conference by means of a
<createconference> request (A1); this conference is properly <createconference> request (A1). This conference is properly
configured according to the use it is assigned to, i.e., to mix configured according to the use it is assigned to, i.e., to mix
all the involved parties accordingly; since only three all the involved parties accordingly. Since only three
participants will be joined to it, 'reserved-talkers' is set to 3; participants will be joined to it, 'reserved-talkers' is set to 3.
'reserved-listeners', on the other hand, is set to 2, since only 'reserved-listeners', on the other hand, is set to 2, since only
the agent and the coach must receive a mix, while the customer 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 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 <dual-view> for the same reason, since only the customer and the
agent must appear in the mix; agent must appear in the mix.
o The MS sends notification of the successful creation of the new o The MS sends notification of the successful creation of the new
conference in a 200 framework message (A2); the identifier conference in a 200 framework message (A2). The identifier
assigned to the conference, which will be used in subsequent assigned to the conference, which will be used in subsequent
requests addressed to it, is 1df080e; requests addressed to it, is 1df080e.
o Now that the conference has been created, the AS joins the three o Now that the conference has been created, the AS joins the three
actors to it with different policies, namely: (i) the customer (A) 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 'sendonly' to the conference (B1), (ii) the agent (B)
is joined as 'sendrecv' to the conference (C1), and (iii) the is joined as 'sendrecv' to the conference (C1), and (iii) the
coach (C) is joined as 'sendrecv' (but audio only) to the coach (C) is joined as 'sendrecv' (but audio only) to the
conference and with a lower volume (D1); the custom policies are conference and with a lower volume (D1). The custom policies are
enforced by means of properly constructed <stream> elements; enforced by means of properly constructed <stream> elements.
o The MS takes care of the requests and acks them (B2, C2, D2); at 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 this point, the conference will receive media from all the actors
but only provide the agent and the coach with the resulting mix; 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 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 'recvonly' (E1). The aim of this request is to provide A with
media too, namely the media contributed by B; this way, A is 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 unaware of the fact that its media are accessed by C by means of
the hidden mixer; the hidden mixer.
o The MS takes care of this request too and acks it (E2), concluding o The MS takes care of this request too and acks it (E2), concluding
the scenario. the scenario.
A1. AS -> MS (CFW CONTROL, createconference) A1. AS -> MS (CFW CONTROL, createconference)
-------------------------------------------- --------------------------------------------
CFW 238e1f2946e8 CONTROL CFW 238e1f2946e8 CONTROL
Control-Package: msc-mixer Control-Package: msc-mixer
Content-Type: application/msc-mixer+xml Content-Type: application/msc-mixer+xml
Content-Length: 329 Content-Length: 329
skipping to change at page 82, line 43 skipping to change at page 82, line 43
the hidden conference and change their connection with the main the hidden conference and change their connection with the main
conference back to 'sendrecv'. After unjoining the main mix and the conference back to 'sendrecv'. After unjoining the main mix and the
sidebar mix, the sidebar conference could then be destroyed. For sidebar mix, the sidebar conference could then be destroyed. For
brevity, and because similar transactions have already been brevity, and because similar transactions have already been
presented, these steps are not described here. presented, these steps are not described here.
In the framework, just as in the previous section, the presented In the framework, just as in the previous section, the presented
scenario can again be achieved by means of the Mixer Control Package. scenario can again be achieved by means of the Mixer Control Package.
The needed steps can be summarized in the following list: The needed steps can be summarized in the following list:
1. First of all, a hidden conference is created (the sidebar mix); 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 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 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 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 while still listening to what's happening in the main conference
in the background); in the background).
3. B and D are detached from the main mix for audio (<modifyjoin> 3. B and D are detached from the main mix for audio (<modifyjoin>
with 'inactive' status); with 'inactive' status).
4. B and D are attached to the hidden sidebar mix for audio. 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> Note that for detaching B and D from the main mix, a <modifyjoin>
with an 'inactive' status is used, instead of an <unjoin>. The with an 'inactive' status is used, instead of an <unjoin>. The
motivation for this is related to how a subsequent rejoining of B and 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> 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 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 remain in place, even if marked as unused at the moment. An
<unjoin>, on the other hand, would actually free those resources, <unjoin>, on the other hand, would actually free those resources,
skipping to change at page 84, line 34 skipping to change at page 84, line 34
| |<<########################################>>| | |<<########################################>>|
| | D is mixed (sendrecv) in the sidebar too | | | D is mixed (sendrecv) in the sidebar too |
| | (A and C can't listen to her/him anymore) | | | (A and C can't listen to her/him anymore) |
| |<<########################################>>| | |<<########################################>>|
| | | | | |
. . . . . .
. . . . . .
Figure 40: Sidebars: Framework Transactions Figure 40: Sidebars: Framework Transactions
o First of all, the hidden conference mix is created (A1); the o First of all, the hidden conference mix is created (A1). The
request is basically the same as that presented in previous request is basically the same as that presented in previous
sections, i.e., a <createconference> request addressed to the sections, i.e., a <createconference> request addressed to the
Mixer package; the request is very lightweight and asks the MS to Mixer package. The request is very lightweight and asks the MS to
only reserve two listener seats ('reserved-listeners', since only only reserve two listener seats ('reserved-listeners', since only
B and D have to hear something) and three talker seats B and D have to hear something) and three talker seats
('reserved-listeners', because in addition to B and D the main mix ('reserved-listeners', because in addition to B and D the main mix
is also an active contributor to the sidebar); the mixing will be is also an active contributor to the sidebar). The mixing will be
driven by directives from the AS (mix-type=controller); when the driven by directives from the AS (mix-type=controller). When the
mix is successfully created, the MS provides the AS with its mix is successfully created, the MS provides the AS with its
identifier (519c1b9); identifier (519c1b9).
o As a first transaction after that, the AS joins the audio from the o As a first transaction after that, the AS joins the audio from the
main conference and the newly created sidebar conference mix (B1); main conference and the newly created sidebar conference mix (B1).
only audio needs to be joined (media=audio), with a 'sendonly' Only audio needs to be joined (media=audio), with a 'sendonly'
direction (i.e., only flowing from the main conference to the direction (i.e., only flowing from the main conference to the
sidebar and not vice versa) and at 30% volume with respect 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 original stream (setgain=-5 dB). A successful completion of the
transaction is reported to the AS (B2); transaction is reported to the AS (B2).
o At this point, the AS makes the connection of B (2133178233: o At this point, the AS makes the connection of B (2133178233:
18294826) and the main conference (2f5ad43) inactive by means of a 18294826) and the main conference (2f5ad43) inactive by means of a
<modifyjoin> directive (C1); the request is taken care of by the <modifyjoin> directive (C1). The request is taken care of by the
MS (C2), and B is actually excluded from the mix for sending as MS (C2), and B is actually excluded from the mix for sending as
well as receiving; well as receiving.
o After that, the AS (D1) joins B (2133178233:18294826) to the o After that, the AS (D1) joins B (2133178233:18294826) to the
sidebar mix created previously (519c1b9); the MS attaches the sidebar mix created previously (519c1b9). The MS attaches the
requested connections and sends confirmation to the AS (D2); requested connections and sends confirmation to the AS (D2).
o The same transactions already done for B are done for D as well o The same transactions already done for B are done for D as well
(id1=1264755310:2beeae5b), i.e., the <modifyjoin> to make the (id1=1264755310:2beeae5b), i.e., the <modifyjoin> to make the
connection in the main conference inactive (E1-2) and the <join> 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 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 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 D will listen to each other and to the conference mix as a
comfortable background. comfortable background.
A1. AS -> MS (CFW CONTROL, createconference) A1. AS -> MS (CFW CONTROL, createconference)
-------------------------------------------- --------------------------------------------
CFW 7fdcc2331bef CONTROL CFW 7fdcc2331bef CONTROL
Control-Package: msc-mixer/1.0 Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml Content-Type: application/msc-mixer+xml
Content-Length: 198 Content-Length: 198
skipping to change at page 89, line 27 skipping to change at page 89, line 27
The scenario will then assume that the Floor Control Server (FCS) is 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 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 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 make the AS directly aware of the floor statuses. For the sake of
simplicity, the scenario assumes that the involved participants are simplicity, the scenario assumes that the involved participants are
already aware of all the identifiers needed in order to make BFCP already aware of all the identifiers needed in order to make BFCP
requests for a specific conference. Such information may have been requests for a specific conference. Such information may have been
carried according to the COMEDIA negotiation as specified in carried according to the COMEDIA negotiation as specified in
[RFC4583]. It is important to note that such information must not [RFC4583]. It is important to note that such information must not
reach the MS: this means that within the context of the 3PCC 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, 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 all the BFCP-related information negotiated by the AS and the UAC
must be removed before making the negotiation available to the MS, must be removed before making the negotiation available to the MS,
which may be unable to understand the specification. A simplified which may be unable to understand the specification. A simplified
example of how this could be achieved is presented in Figure 41. example of how this could be achieved is presented in Figure 41.
Please note that within the context of this example scenario, Please note that within the context of this example scenario,
different identifiers may be used to address the same entity: different identifiers may be used to address the same entity.
specifically, in this case the UAC (the endpoint sending and Specifically, in this case the UAC (the endpoint sending and
receiving media) is also a FCP, as it negotiates a BFCP channel too. receiving media) is also a FCP, as it negotiates a BFCP channel too.
UAC AS UAC AS
(FCP) (FCS) MS (FCP) (FCS) MS
| | | | | |
| INVITE (SDP: RTP+BFCP) | | | INVITE (SDP: RTP+BFCP) | |
|-------------------------------->| | |-------------------------------->| |
| | INVITE (SDP: RTP) | | | INVITE (SDP: RTP) |
| |-------------------------------->| | |-------------------------------->|
| | 200 (SDP: RTP'+labels) | | | 200 (SDP: RTP'+labels) |
skipping to change at page 91, line 21 skipping to change at page 91, line 21
Chair (FCC). Chair (FCC).
As in all of the previously described conferencing examples, in the As in all of the previously described conferencing examples, in the
framework this can be achieved by means of the Mixer Control Package. framework this can be achieved by means of the Mixer Control Package.
Assuming that the conference has been created, the participant has Assuming that the conference has been created, the participant has
been attached ('recvonly') to it, and the participant is aware of the been attached ('recvonly') to it, and the participant is aware of the
involved BFCP identifiers, the needed steps can be summarized in the involved BFCP identifiers, the needed steps can be summarized in the
following list: following list:
1. The assigned chair, FCC, sends a subscription for events related 1. The assigned chair, FCC, sends a subscription for events related
to the floor for which it is responsible (FloorQuery); to the floor for which it is responsible (FloorQuery).
2. The FCP sends a BFCP request (FloorRequest) to access the audio 2. The FCP sends a BFCP request (FloorRequest) to access the audio
resource ("I want to speak"); resource ("I want to speak").
3. The FCS (AS) sends a provisional response to the FCP 3. The FCS (AS) sends a provisional response to the FCP
(FloorRequestStatus PENDING) and handles the request in its (FloorRequestStatus PENDING) and handles the request in its
queue; since a chair is assigned to this floor, the request is queue. Since a chair is assigned to this floor, the request is
forwarded to the FCC for a decision (FloorStatus); forwarded to the FCC for a decision (FloorStatus).
4. The FCC makes a decision and sends it to the FCS (ChairAction 4. The FCC makes a decision and sends it to the FCS (ChairAction
ACCEPTED); ACCEPTED).
5. The FCS takes note of the decision and updates the queue 5. The FCS takes note of the decision and updates the queue
accordingly; the decision is sent to the FCP (FloorRequestStatus accordingly. The decision is sent to the FCP (FloorRequestStatus
ACCEPTED); the floor has not been granted yet; ACCEPTED). The floor has not been granted yet.
6. As soon as the queue allows it, the floor is actually granted to 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 the FCP. The AS, which is co-located with the FCS, understands
its business logic that such an event is associated with the in its business logic that such an event is associated with the
audio resource being granted to the FCP; as a consequence, a audio resource being granted to the FCP. As a consequence, a
<modifyjoin> ('sendrecv') is sent through the Control Channel to <modifyjoin> ('sendrecv') is sent through the Control Channel to
the MS in order to unmute the FCP UAC in the conference; the MS in order to unmute the FCP UAC in the conference.
7. The FCP is notified of this event (FloorRequestStatus GRANTED), 7. The FCP is notified of this event (FloorRequestStatus GRANTED),
thus ending the scenario. thus ending the scenario.
A diagram of such a sequence of transactions (also involving the BFCP A diagram of such a sequence of transactions (also involving the BFCP
message flow at a higher level) is depicted in Figure 43: message flow at a higher level) is depicted in Figure 43:
UAC1 UAC2 AS UAC1 UAC2 AS
(FCP) (FCC) (FCS) MS (FCP) (FCC) (FCS) MS
| | | | | | | |
skipping to change at page 93, line 29 skipping to change at page 93, line 29
interaction at the BFCP level only results in a single transaction at interaction at the BFCP level only results in a single transaction at
the MEDIACTRL level. In fact, the purpose of the BFCP transactions the MEDIACTRL level. In fact, the purpose of the BFCP transactions
is to moderate access to the audio resource, which means providing is to moderate access to the audio resource, which means providing
the event trigger to MEDIACTRL-based conference manipulation the event trigger to MEDIACTRL-based conference manipulation
transactions. Before being granted the floor, the FCP UAC is transactions. Before being granted the floor, the FCP UAC is
excluded from the conference mix at the MEDIACTRL level ('recvonly'). 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 As soon as the floor has been granted, the FCP UAC is included in the
mix. In MEDIACTRL words: mix. In MEDIACTRL words:
o Since the FCP UAC must be included in the audio mix, a 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> is sent to the MS in a CONTROL directive. The
<modifyjoin> has as identifiers the connectionid associated with <modifyjoin> has as identifiers the connectionid associated with
the FCP UAC (e1e1427c:1c998d22) and the conferenceid of the mix the FCP UAC (e1e1427c:1c998d22) and the conferenceid of the mix
(cf45ee2); the <stream> element tells the MS that the audio media (cf45ee2). The <stream> element tells the MS that the audio media
stream between the two must become bidirectional ('sendrecv'), stream between the two must become bidirectional ('sendrecv'),
changing the previous status ('recvonly'); please note that in changing the previous status ('recvonly'). Please note that in
this case only audio was involved in the conference; if video were this case only audio was involved in the conference; if video were
involved as well, and video had to be unchanged, a <stream> involved as well, and video had to be unchanged, a <stream>
directive for video had to be placed in the request as well in directive for video had to be placed in the request as well in
order to maintain its current status. order to maintain its current status.
1. AS -> MS (CFW CONTROL) 1. AS -> MS (CFW CONTROL)
------------------------- -------------------------
CFW gh67ffg56w21 CONTROL CFW gh67ffg56w21 CONTROL
Control-Package: msc-mixer/1.0 Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml Content-Type: application/msc-mixer+xml
skipping to change at page 94, line 39 skipping to change at page 94, line 39
6.4. Additional Scenarios 6.4. Additional Scenarios
This section includes additional scenarios that can be of interest This section includes additional scenarios that can be of interest
when dealing with AS<->MS flows. The aim of the following when dealing with AS<->MS flows. The aim of the following
subsections is to present the use of features peculiar to the IVR subsections is to present the use of features peculiar to the IVR
package: specifically, variable announcements, VCR (video cassette package: specifically, variable announcements, VCR (video cassette
recorder) prompts, parallel playback, recurring dialogs, and custom recorder) prompts, parallel playback, recurring dialogs, and custom
grammars. To describe how call flows involving such features might grammars. To describe how call flows involving such features might
happen, three sample scenarios have been chosen: happen, three sample scenarios have been chosen:
1. Voice Mail (variable announcements for digits, VCR controls); 1. Voice Mail (variable announcements for digits, VCR controls).
2. Current Time (variable announcements for date and time, parallel 2. Current Time (variable announcements for date and time, parallel
playback); playback).
3. DTMF-driven Conference Manipulation (recurring dialogs, custom 3. DTMF-driven Conference Manipulation (recurring dialogs, custom
grammars). grammars).
6.4.1. Voice Mail 6.4.1. Voice Mail
An application that typically uses the services an MS can provide is An application that typically uses the services an MS can provide is
Voice Mail. In fact, while it is clear that many of its features are Voice Mail. In fact, while it is clear that many of its features are
part of the application logic (e.g., the mapping of a URI with a part of the application logic (e.g., the mapping of a URI with a
specific user's voice mailbox, the list of messages and their specific user's voice mailbox, the list of messages and their
properties, and so on), the actual media work is accomplished through properties, and so on), the actual media work is accomplished through
the MS. Features needed by a Voice Mail application include the the MS. Features needed by a Voice Mail application include the
ability to record a stream and play it back at a later time, give ability to record a stream and play it back at a later time, give
verbose announcements regarding the status of the application, verbose announcements regarding the status of the application,
control the playout of recorded messages by means of VCR controls, control the playout of recorded messages by means of VCR controls,
and so on; these features are all supported by the MS through the IVR and so on. These features are all supported by the MS through the
package. IVR package.
Without delving into the details of a full Voice Mail application and Without delving into the details of a full Voice Mail application and
all its possible use cases, this section will cover a specific all its possible use cases, this section will cover a specific
scenario and try to deal with as many interactions as possible that scenario and try to deal with as many interactions as possible that
may happen between the AS and the MS in such a context. This may happen between the AS and the MS in such a context. This
scenario, depicted as a sequence diagram in Figure 44, will be as scenario, depicted as a sequence diagram in Figure 44, will be as
follows: follows:
1. The UAC INVITEs a URI associated with his mailbox, and the AS 1. The UAC INVITEs a URI associated with his mailbox, and the AS
follows the previously explained procedure to have the UAC follows the previously explained procedure to have the UAC
negotiate a new media session with the MS; negotiate a new media session with the MS.
2. The UAC is first prompted with an announcement giving him the 2. The UAC is first prompted with an announcement giving him the
amount of available new messages in the mailbox; after that, the amount of available new messages in the mailbox. After that, the
UAC can choose which message to access by sending a DTMF tone; UAC can choose which message to access by sending a DTMF tone.
3. The UAC is then presented with a VCR-controlled announcement, in 3. The UAC is then presented with a VCR-controlled announcement, in
which the chosen received mail is played back to him; VCR which the chosen received mail is played back to him. VCR
controls allow him to navigate through the prompt. controls allow him to navigate through the prompt.
This is a quite oversimplified scenario, considering that it doesn't This is a quite oversimplified scenario, considering that it doesn't
even allow the UAC to delete old messages or organize them but just even allow the UAC to delete old messages or organize them but just
to choose which received message to play. Nevertheless, it gives us to choose which received message to play. Nevertheless, it gives us
the chance to deal with variable announcements and VCR controls -- the chance to deal with variable announcements and VCR controls --
two typical features that a Voice Mail application would almost two typical features that a Voice Mail application would almost
always take advantage of. Other features that a Voice Mail always take advantage of. Other features that a Voice Mail
application would rely upon (e.g., recording streams, event-driven application would rely upon (e.g., recording streams, event-driven
IVR menus, and so on) have been introduced in previous sections, and IVR menus, and so on) have been introduced in previous sections, and
skipping to change at page 97, line 13 skipping to change at page 97, line 13
| |++++++++++++++++++++++++++++++++>>| | |++++++++++++++++++++++++++++++++>>|
| | | | | |
. . . . . .
. . . . . .
Figure 44: Voice Mail: Framework Transactions Figure 44: Voice Mail: Framework Transactions
The framework transaction steps are as follows: The framework transaction steps are as follows:
o The first transaction (A1) is addressed to the IVR package (msc- o The first transaction (A1) is addressed to the IVR package (msc-
ivr); it is basically an [RFC6231] 'promptandcollect' dialog, but ivr). It is basically an [RFC6231] 'promptandcollect' dialog, but
with a slight difference: some of the prompts to play are actual with a slight difference: some of the prompts to play are actual
audio files, for which a URI is provided (media loc="xxx"), while audio files, for which a URI is provided (media loc="xxx"), while
others are so-called <variable> prompts; these <variable> prompts others are so-called <variable> prompts; these <variable> prompts
are actually constructed by the MS itself according to the are actually constructed by the MS itself according to the
directives provided by the AS; in this example, the sequence of directives provided by the AS. In this example, the sequence of
prompts requested by the AS is as follows: prompts requested by the AS is as follows:
1. play a wav file ("you have..."); 1. play a wav file ("you have...").
2. play a digit ("five...") by building it (variable: digit=5); 2. play a digit ("five...") by building it (variable: digit=5).
3. play a wav file ("messages..."). 3. play a wav file ("messages...").
A DTMF collection is requested as well (<collect>) to be taken A DTMF collection is requested as well (<collect>) to be taken
after the prompts have been played; the AS is only interested in a after the prompts have been played. The AS is only interested in
single digit (maxdigits=1); a single digit (maxdigits=1).
o The transaction is handled by the MS, and if everything works fine o The transaction is handled by the MS, and if everything works fine
(i.e., the MS retrieved all the audio files and successfully built (i.e., the MS retrieved all the audio files and successfully built
the variable announcements), the dialog is started; its start is the variable announcements), the dialog is started; its start is
reported, together with the associated identifier (5db01f4) to the reported, together with the associated identifier (5db01f4) to the
AS in a terminating 200 OK message (A2); AS in a terminating 200 OK message (A2).
o The AS then waits for the dialog to end in order to retrieve the o The AS then waits for the dialog to end in order to retrieve the
results in which it is interested (in this case, the DTMF tone the results in which it is interested (in this case, the DTMF tone the
UAC chooses, since it will affect which message will have to be UAC chooses, since it will affect which message will have to be
played subsequently); played subsequently).
o The UAC hears the prompts and chooses a message to play; in this o The UAC hears the prompts and chooses a message to play. In this
example, he wants to listen to the first message and so inputs example, he wants to listen to the first message and so inputs
"1"; the MS intercepts this tone and notifies the AS of it in a "1". The MS intercepts this tone and notifies the AS of it in a
newly created CONTROL event message (B1); this CONTROL includes newly created CONTROL event message (B1); this CONTROL includes
information about how each single requested operation ended information about how each single requested operation ended
(<promptinfo> and <collectinfo>); specifically, the event states (<promptinfo> and <collectinfo>). Specifically, the event states
that the prompt ended normally (termmode=completed) and that the that the prompt ended normally (termmode=completed) and that the
subsequently collected tone is 1 (dtmf=1); the AS acks the event subsequently collected tone is 1 (dtmf=1). The AS acks the event
(B2), since the dialogid provided in the message is the same as (B2), since the dialogid provided in the message is the same as
that of the previously started dialog; that of the previously started dialog.
o At this point, the AS uses the value retrieved from the event to o At this point, the AS uses the value retrieved from the event to
proceed with its business logic; it decides to present the UAC proceed with its business logic. It decides to present the UAC
with a VCR-controllable playout of the requested message; this is with a VCR-controllable playout of the requested message. This is
done with a new request to the IVR package (C1), which contains done with a new request to the IVR package (C1), which contains
two operations: <prompt> to address the media file to play (an old two operations: <prompt> to address the media file to play (an old
recording) and <control> to instruct the MS about how the playout recording) and <control> to instruct the MS about how the playout
of this media file shall be controlled via DTMF tones provided by of this media file shall be controlled via DTMF tones provided by
the UAC (in this example, different DTMF digits are associated the UAC (in this example, different DTMF digits are associated
with different actions, e.g., pause/resume, fast forward, rewind, with different actions, e.g., pause/resume, fast forward, rewind,
and so on); the AS also subscribes to DTMF events related to this and so on). The AS also subscribes to DTMF events related to this
control operation (matchmode=control), which means that the MS is control operation (matchmode=control), which means that the MS is
to trigger an event any time that a DTMF associated with a control to trigger an event any time that a DTMF associated with a control
operation (e.g., 7=pause) is intercepted; operation (e.g., 7=pause) is intercepted.
o The MS prepares the dialog and, when the playout starts, sends o The MS prepares the dialog and, when the playout starts, sends
notification in a terminating 200 OK message (C2); at this point, notification in a terminating 200 OK message (C2). At this point,
the UAC is presented with the prompt and can use DTMF digits to the UAC is presented with the prompt and can use DTMF digits to
control the playback; control the playback.
o As explained previously, any DTMF associated with a VCR operation o As explained previously, any DTMF associated with a VCR operation
is then reported to the AS, together with a timestamp stating when is then reported to the AS, together with a timestamp stating when
the event happened; an example is provided (D1) in which the UAC the event happened. An example is provided (D1) in which the UAC
pressed the fast-forward key (6) at a specific time; of course, as pressed the fast-forward key (6) at a specific time. Of course,
for any other MS-generated event, the AS acks it (D2); as for any other MS-generated event, the AS acks it (D2).
o When the playback ends (whether because the media reached its o When the playback ends (whether because the media reached its
termination or because any other interruption occurred), the MS termination or because any other interruption occurred), the MS
triggers a concluding event with information about the whole triggers a concluding event with information about the whole
dialog (E1); this event, besides including information about the dialog (E1). This event, besides including information about the
prompt itself (<promptinfo>), also includes information related to prompt itself (<promptinfo>), also includes information related to
the VCR operations (<controlinfo>), that is, all the VCR controls the VCR operations (<controlinfo>), that is, all the VCR controls
the UAC used (fast forward/rewind/pause/resume in this example) the UAC used (fast forward/rewind/pause/resume in this example)
and when it happened; the final ack by the AS (E2) concludes the and when it happened. The final ack by the AS (E2) concludes the
scenario. scenario.
A1. AS -> MS (CFW CONTROL, play and collect) A1. AS -> MS (CFW CONTROL, play and collect)
-------------------------------------------- --------------------------------------------
CFW 2f931de22820 CONTROL CFW 2f931de22820 CONTROL
Control-Package: msc-ivr/1.0 Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml Content-Type: application/msc-ivr+xml
Content-Length: 429 Content-Length: 429
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
skipping to change at page 102, line 16 skipping to change at page 102, line 16
dates and times. dates and times.
To make the scenario more interesting and have it cover more To make the scenario more interesting and have it cover more
functionality, the application is also assumed to have background functionality, the application is also assumed to have background
music played during the announcement. Because most of the music played during the announcement. Because most of the
announcements will be variable, a means is needed to have more announcements will be variable, a means is needed to have more
streams played in parallel on the same connection. This can be streams played in parallel on the same connection. This can be
achieved in two different ways: achieved in two different ways:
1. two separate and different dialogs, playing the variable 1. two separate and different dialogs, playing the variable
announcements and the background track, respectively; announcements and the background track, respectively.
2. a single dialog implementing a parallel playback. 2. a single dialog implementing a parallel playback.
The first approach assumes that the available MS implements implicit The first approach assumes that the available MS implements implicit
mixing, which may or may not be supported since it's a recommended mixing, which may or may not be supported since it's a recommended
feature but not mandatory. The second approach assumes that the MS feature but not mandatory. The second approach assumes that the MS
implements support for more streams of the same media type (in this implements support for more streams of the same media type (in this
case audio) in the same dialog, which, exactly as for the case of case audio) in the same dialog, which, exactly as for the case of
implicit mixing, is not to be taken for granted. Because the first implicit mixing, is not to be taken for granted. Because the first
approach is quite straightforward and easy to understand, the approach is quite straightforward and easy to understand, the
following scenario uses the second approach and assumes that the following scenario uses the second approach and assumes that the
available MS supports parallel playback of more audio tracks within available MS supports parallel playback of more audio tracks within
the context of the same dialog. the context of the same dialog.
That said, the covered scenario, depicted as a sequence diagram in That said, the covered scenario, depicted as a sequence diagram in
Figure 45, will be as follows: Figure 45, will be as follows:
1. The UAC INVITEs a URI associated with the Current Time 1. The UAC INVITEs a URI associated with the Current Time
application, and the AS follows the previously explained application, and the AS follows the previously explained
procedure to have the UAC negotiate a new media session with the procedure to have the UAC negotiate a new media session with the
MS; MS.
2. The UAC is presented with an announcement including (i) a voice 2. The UAC is presented with an announcement including (i) a voice
stating the current date and time; (ii) a background music track; stating the current date and time; (ii) a background music track;
and (iii) a mute background video track. and (iii) a mute background video track.
UAC AS MS UAC AS MS
| | | | | |
| | A1. CONTROL (play variables) | | | A1. CONTROL (play variables) |
| |++++++++++++++++++++++++++++++++>>| prepare | |++++++++++++++++++++++++++++++++>>| prepare
| | |--+ and | | |--+ and
skipping to change at page 103, line 37 skipping to change at page 103, line 37
| | | | | |
. . . . . .
. . . . . .
. . . . . .
Figure 45: Current Time: Framework Transactions Figure 45: Current Time: Framework Transactions
The framework transaction steps are as follows: The framework transaction steps are as follows:
o The first transaction (A1) is addressed to the IVR package (msc- o The first transaction (A1) is addressed to the IVR package (msc-
ivr). It is basically an [RFC6231] 'playannouncements' dialog, ivr); it is basically an [RFC6231] 'playannouncements' dialog,
but, unlike all the scenarios presented so far, it includes but, unlike all the scenarios presented so far, it includes
directives for a parallel playback, as indicated by the <par> directives for a parallel playback, as indicated by the <par>
element. There are three flows to play in parallel: element. There are three flows to play in parallel:
* a sequence (<seq>) of variable and static announcements (the * a sequence (<seq>) of variable and static announcements (the
actual time and date); actual time and date).
* a music track ('media=music.wav') to be played in the * a music track ('media=music.wav') to be played in the
background at a lower volume (soundLevel=50%); background at a lower volume (soundLevel=50%).
* a mute background video track (media=clock.mpg). * a mute background video track (media=clock.mpg).
The global announcement ends when the longest of the three The global announcement ends when the longest of the three
parallel steps ends (endsync=last). This means that if one of the parallel steps ends (endsync=last). This means that if one of the
steps ends before the others, the step is muted for the rest of steps ends before the others, the step is muted for the rest of
the playback. In this example, the series of static and the playback. In this example, the series of static and
<variable> announcements is requested by the AS: <variable> announcements is requested by the AS:
* play a wav file ("Tuesday..."); * play a wav file ("Tuesday...").
* play a date ("16th of december 2008...") by building it * play a date ("16th of december 2008...") by building it
(variable: date with a ymd=year/month/day format); (variable: date with a ymd=year/month/day format).
* play a time ("5:31 PM...") by building it (variable: time with * play a time ("5:31 PM...") by building it (variable: time with
a t12=12 hour day format, am/pm). a t12=12 hour day format, am/pm).
o The transaction is extended by the MS (A2) with a new timeout, as o The transaction is extended by the MS (A2) with a new timeout, as
in this case the MS needs some more time to retrieve all the in this case the MS needs some more time to retrieve all the
needed media files. Should the new timeout expire as well, the MS needed media files. Should the new timeout expire as well, the MS
would send a further message to extend it again (a REPORT update), would send a further message to extend it again (a REPORT update),
but for the sake of simplicity we assume that in this scenario it but for the sake of simplicity we assume that in this scenario it
is not needed. If everything went fine (i.e., the MS retrieved is not needed. If everything went fine (i.e., the MS retrieved
skipping to change at page 106, line 40 skipping to change at page 106, line 40
and so on. To achieve all this, the simplest thing an AS can do is and so on. To achieve all this, the simplest thing an AS can do is
to prepare a recurring DTMF collection for each participant with to prepare a recurring DTMF collection for each participant with
specific grammars to match. If the collected tones match the specific grammars to match. If the collected tones match the
grammar, the MS would notify the AS of the tones and start the grammar, the MS would notify the AS of the tones and start the
collection again. Upon receipt of <collectinfo> events, the AS would collection again. Upon receipt of <collectinfo> events, the AS would
in turn originate the proper related request, e.g., a <modifyjoin> on in turn originate the proper related request, e.g., a <modifyjoin> on
the participant's stream with the conference. This is made possible the participant's stream with the conference. This is made possible
by three features provided by the IVR package: by three features provided by the IVR package:
1. the 'repeatCount' attribute; 1. the 'repeatCount' attribute.
2. the subscription mechanism; 2. the subscription mechanism.
3. the Speech Recognition Grammar Specification (SRGS) [SRGS]. 3. the Speech Recognition Grammar Specification (SRGS) [SRGS].
The first feature allows recurring instances of the same dialog The first feature allows recurring instances of the same dialog
without the need for additional requests upon completion of the without the need for additional requests upon completion of the
dialog itself. In fact, the 'repeatCount' attribute indicates how dialog itself. In fact, the 'repeatCount' attribute indicates how
many times the dialog has to be repeated: when the attribute has the many times the dialog has to be repeated. When the attribute has the
value 0, it means that the dialog has to be repeated indefinitely, value 0, it means that the dialog has to be repeated indefinitely,
meaning that it's up to the AS to destroy it by means of a meaning that it's up to the AS to destroy it by means of a
<dialogterminate> request when the dialog is no longer needed. The <dialogterminate> request when the dialog is no longer needed. The
second feature allows the AS to subscribe to events related to the second feature allows the AS to subscribe to events related to the
IVR package without waiting for the dialog to end, e.g., matching IVR package without waiting for the dialog to end, e.g., matching
DTMF collections in this case. Finally, the last feature allows DTMF collections in this case. Finally, the last feature allows
custom matching grammars to be specified: this way, only a subset of custom matching grammars to be specified. This way, only a subset of
the possible DTMF strings can be specified, so that only those the possible DTMF strings can be specified, so that only those
matches in which the AS is interested are reported. Grammars other matches in which the AS is interested are reported. Grammars other
than SRGS may be supported by the MS and will achieve the same than SRGS may be supported by the MS and will achieve the same
result; this document will only describe the use of an SRGS grammar, result. This document will only describe the use of an SRGS grammar,
since support for SRGS is mandated in [RFC6231]. since support for SRGS is mandated in [RFC6231].
To identify a single sample scenario, we assume that a participant To identify a single sample scenario, we assume that a participant
has successfully joined a conference, e.g., as detailed in Figure 32. has successfully joined a conference, e.g., as detailed in Figure 32.
We also assume that the following codes are to be provided within the We also assume that the following codes are to be provided within the
conference to participants in order to let them take advantage of conference to participants in order to let them take advantage of
advanced features: advanced features:
1. *6 to mute/unmute themselves (on/off trigger); 1. *6 to mute/unmute themselves (on/off trigger).
2. *1 to lower their own volume in the conference and *3 to raise 2. *1 to lower their own volume in the conference and *3 to raise
it; it.
3. *7 to lower the volume of the conference stream they are 3. *7 to lower the volume of the conference stream they are
receiving and *9 to raise it; receiving and *9 to raise it.
4. *0 to leave the conference. 4. *0 to leave the conference.
This means that six different codes are supported and are to be This means that six different codes are supported and are to be
matched in the requested DTMF collection. All other codes are matched in the requested DTMF collection. All other codes are
collected by the MS but discarded, and no event is triggered to the collected by the MS but discarded, and no event is triggered to the
AS. Because all the codes have the '*' (star) DTMF code in common, AS. Because all the codes have the '*' (star) DTMF code in common,
the following is an example of an SRGS grammar that may be used in the following is an example of an SRGS grammar that may be used in
the request by the AS: the request by the AS:
skipping to change at page 108, line 26 skipping to change at page 108, line 26
</rule> </rule>
<rule id="action" scope="public"> <rule id="action" scope="public">
<item> <item>
* *
<item><ruleref uri="#digit"/></item> <item><ruleref uri="#digit"/></item>
</item> </item>
</rule> </rule>
</grammar> </grammar>
As can be deduced by looking at the grammar, the presented SRGS XML As can be deduced by looking at the grammar, the presented SRGS XML
code specifies exactly the requirements for the collections to match: code specifies exactly the requirements for the collections to match.
the rule is to match any string that has a star ('*') followed by a The rule is to match any string that has a star ('*') followed by a
single supported digit (0, 1, 3, 6, 7, or 9). Such grammar, as single supported digit (0, 1, 3, 6, 7, or 9). Such grammar, as
stated in [RFC6231], may be either provided inline in the request stated in [RFC6231], may be either provided inline in the request
itself or referenced externally by means of the 'src' attribute. In itself or referenced externally by means of the 'src' attribute. In
the example scenario, we'll put it inline, but an external reference the example scenario, we'll put it inline, but an external reference
to the same document would achieve exactly the same result. to the same document would achieve exactly the same result.
Figure 46 shows how the AS might request the recurring collection for Figure 46 shows how the AS might request the recurring collection for
a UAC. As before, the example assumes that the UAC is already a a UAC. As before, the example assumes that the UAC is already a
participant in the conference. participant in the conference.
skipping to change at page 110, line 46 skipping to change at page 110, line 46
| | | | | |
. . . . . .
. . . . . .
Figure 46: DTMF-Driven Conference Manipulation: Framework Figure 46: DTMF-Driven Conference Manipulation: Framework
Transactions Transactions
As can be deduced from the sequence diagram above, the AS, in its As can be deduced from the sequence diagram above, the AS, in its
business logic, correlates the results of different transactions, business logic, correlates the results of different transactions,
addressed to different packages, to implement a more complex addressed to different packages, to implement a more complex
conferencing scenario: in fact, <dtmfnotify> events are used to take conferencing scenario. In fact, <dtmfnotify> events are used to take
actions according to the functions of the DTMF codes. The framework actions according to the functions of the DTMF codes. The framework
transaction steps are as follows: transaction steps are as follows:
o The UAC is already in the conference, and so the AS starts a o The UAC is already in the conference, and so the AS starts a
recurring collect with a grammar to match. This is done by recurring collect with a grammar to match. This is done by
placing a CONTROL request addressed to the IVR package (A1); the placing a CONTROL request addressed to the IVR package (A1). The
operation to implement is a <collect>, and we are only interested operation to implement is a <collect>, and we are only interested
in two-digit DTMF strings (maxdigits). The AS is not interested in two-digit DTMF strings (maxdigits). The AS is not interested
in a DTMF terminator (termchar is set to a non-conventional DTMF in a DTMF terminator (termchar is set to a non-conventional DTMF
character), and the DTMF escape key is set to '#' (the default is character), and the DTMF escape key is set to '#' (the default is
'*', which would conflict with the code syntax for the conference '*', which would conflict with the code syntax for the conference
and so needs to be changed). A custom SRGS grammar is provided and so needs to be changed). A custom SRGS grammar is provided
inline (<grammar> with mode=dtmf). The whole dialog is to be inline (<grammar> with mode=dtmf). The whole dialog is to be
repeated indefinitely (dialog has repeatCount=0), and the AS wants repeated indefinitely (dialog has repeatCount=0), and the AS wants
to be notified when matching collections occur (dtmfsub with to be notified when matching collections occur (dtmfsub with
matchmode=collect). matchmode=collect).
skipping to change at page 111, line 37 skipping to change at page 111, line 37
immediately restarts the collection. immediately restarts the collection.
o The AS acks the event (B2) and in its business logic understands o The AS acks the event (B2) and in its business logic understands
that the code '*1' means that the UAC wants its own volume to be that the code '*1' means that the UAC wants its own volume to be
lowered in the conference mix. The AS is able to associate the lowered in the conference mix. The AS is able to associate the
event with the right UAC by referring to the attached dialogid event with the right UAC by referring to the attached dialogid
(01d1b38). It then acts accordingly by sending a <modifyjoin> (01d1b38). It then acts accordingly by sending a <modifyjoin>
(C1) that does exactly this: the provided <stream> child element (C1) that does exactly this: the provided <stream> child element
instructs the MS to modify the volume of the UAC-->conference instructs the MS to modify the volume of the UAC-->conference
audio flow (setgain=-5 dB 'sendonly'). Note that the "setgain" audio flow (setgain=-5 dB 'sendonly'). Note that the "setgain"
value is the absolute volume level; if the user's request is to value is the absolute volume level. If the user's request is to
lower the volume level, the AS must remember the previously set lower the volume level, the AS must remember the previously set
volume level and from it calculate the new volume level. Note how volume level and from it calculate the new volume level. Note how
the request also includes directives for the inverse direction. the request also includes directives for the inverse direction.
This verbose approach is needed; otherwise, the MS would not only This verbose approach is needed; otherwise, the MS would not only
change the volume in the requested direction but would also change the volume in the requested direction but would also
disable the media flow in the other direction. Having a proper disable the media flow in the other direction. Having a proper
<stream> addressing the UAC<--conf media flow as well ensures that <stream> addressing the UAC<--conf media flow as well ensures that
this doesn't happen. this doesn't happen.
o The MS successfully enforces the requested operation (C2), o The MS successfully enforces the requested operation (C2),
skipping to change at page 112, line 37 skipping to change at page 112, line 37
o A last (in this scenario) matching DTMF string is collected by the o A last (in this scenario) matching DTMF string is collected by the
MS (*0). As with all the previous codes, notification of this MS (*0). As with all the previous codes, notification of this
string is sent to the AS (H1). string is sent to the AS (H1).
o The AS acks the event (H2) and understands that the UAC wants to o The AS acks the event (H2) and understands that the UAC wants to
leave the conference now (since the code is *0). This means that leave the conference now (since the code is *0). This means that
a series of actions must be taken: a series of actions must be taken:
* The recurring collection is stopped, since it's no longer * The recurring collection is stopped, since it's no longer
needed; needed.
* The UAC is unjoined from the conference it is in; * The UAC is unjoined from the conference it is in.
* Additional operations might be considered, e.g., a global * Additional operations might be considered, e.g., a global
announcement stating that the UAC is leaving, but for the sake announcement stating that the UAC is leaving, but for the sake
of conciseness such operations are not listed here. of conciseness such operations are not listed here.
The former is accomplished by means of a <dialogterminate> request The former is accomplished by means of a <dialogterminate> request
(I1) to the IVR package (dialogid=01d1b38) and the latter by means (I1) to the IVR package (dialogid=01d1b38) and the latter by means
of an <unjoin> request (K1) to the Mixer package. of an <unjoin> request (K1) to the Mixer package.
o The <dialogterminate> request is handled by the MS (I2), and the o The <dialogterminate> request is handled by the MS (I2), and the
skipping to change at page 120, line 11 skipping to change at page 120, line 11
called the Media Resource Broker (MRB) has been introduced in the called the Media Resource Broker (MRB) has been introduced in the
MEDIACTRL architecture. Such an entity, and the protocols needed to MEDIACTRL architecture. Such an entity, and the protocols needed to
interact with it, has been standardized in [RFC6917]. interact with it, has been standardized in [RFC6917].
An MRB is basically a locator that is aware of a pool of MS and makes An MRB is basically a locator that is aware of a pool of MS and makes
them available to interested AS according to their requirements. For them available to interested AS according to their requirements. For
this reason, two different interfaces have been introduced: this reason, two different interfaces have been introduced:
o the Publishing interface (Section 7.1), which allows an MRB to o the Publishing interface (Section 7.1), which allows an MRB to
subscribe for notifications at the MS it is handling (e.g., subscribe for notifications at the MS it is handling (e.g.,
available and occupied resources, current state, etc.); available and occupied resources, current state, etc.).
o the Consumer interface (Section 7.2), which allows an interested o the Consumer interface (Section 7.2), which allows an interested
AS to query an MRB for an MS capable of fulfilling its AS to query an MRB for an MS capable of fulfilling its
requirements. requirements.
The flows in the following sections will present some typical use- The flows in the following sections will present some typical use-
case scenarios involving an MRB and the different topologies in which case scenarios involving an MRB and the different topologies in which
it has been conceived to work. it has been conceived to work.
Additionally, a few considerations on the handling of media dialogs Additionally, a few considerations on the handling of media dialogs
skipping to change at page 123, line 5 skipping to change at page 123, line 5
In this example, the MRB subscribes for information at the specified In this example, the MRB subscribes for information at the specified
MS, and events are triggered on a regular, negotiated basis. All of MS, and events are triggered on a regular, negotiated basis. All of
these messages flow through the Control Channel, as do all of the these messages flow through the Control Channel, as do all of the
messages discussed in this document. The framework transaction steps messages discussed in this document. The framework transaction steps
are as follows: are as follows:
o The MRB sends a new CONTROL message (A1) addressed to the MRB o The MRB sends a new CONTROL message (A1) addressed to the MRB
package (mrb-publish/1.0); it is a subscription for information package (mrb-publish/1.0); it is a subscription for information
(<subscription>), and the MRB is asking to be notified at least (<subscription>), and the MRB is asking to be notified at least
every 10 minutes (<minfrequency>) or, if required, every 30 every 10 minutes (<minfrequency>) or, if required, every 30
seconds at maximum; the subscription must last 30 minutes seconds at maximum. The subscription must last 30 minutes
(<expires>), after which no additional notifications must be sent; (<expires>), after which no additional notifications must be sent.
o The MS acknowledges the request (A2) and sends notification of the o The MS acknowledges the request (A2) and sends notification of the
success of the request in a 200 OK message (<mrbresponse>); success of the request in a 200 OK message (<mrbresponse>).
o The MS prepares and sends the first notification to the MRB (B1); o The MS prepares and sends the first notification to the MRB (B1).
as has been done with other packages, the notification has been As has been done with other packages, the notification has been
sent as an MS-generated CONTROL message; it is a notification sent as an MS-generated CONTROL message; it is a notification
related to the request in the first message, because the 'id' related to the request in the first message, because the 'id'
(p0T65U) matches that request; all of the information that the MRB (p0T65U) matches that request. All of the information that the
subscribed for is provided in the payload; MRB subscribed for is provided in the payload.
o The MRB acknowledges the notification (B2) and uses the retrieved o The MRB acknowledges the notification (B2) and uses the retrieved
information to update its own information as part of its business information to update its own information as part of its business
logic; logic.
o The previous step (the MRB acknowledges notifications and uses the o The previous step (the MRB acknowledges notifications and uses the
retrieved information) repeats at the required frequency, with retrieved information) repeats at the required frequency, with
up-to-date information; up-to-date information.
o After a while, the MRB updates its subscription (D1) to get more o After a while, the MRB updates its subscription (D1) to get more
frequent updates (minfrequency=1, an update every second at frequent updates (minfrequency=1, an update every second at
least); the MS accepts the update (D2), although it may adjust the least). The MS accepts the update (D2), although it may adjust
frequency in the reply according to its policies (e.g., a lower the frequency in the reply according to its policies (e.g., a
rate, such as minfrequency=30); the notifications continue, but at lower rate, such as minfrequency=30). The notifications continue,
the newer rate; the expiration is also updated accordingly (600 but at the newer rate; the expiration is also updated accordingly
seconds again, since the update refreshes it). (600 seconds again, since the update refreshes it).
A1. MRB -> MS (CONTROL, publish request) A1. MRB -> MS (CONTROL, publish request)
---------------------------------------- ----------------------------------------
CFW lidc30BZObiC CONTROL CFW lidc30BZObiC CONTROL
Control-Package: mrb-publish/1.0 Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml Content-Type: application/mrb-publish+xml
Content-Length: 337 Content-Length: 337
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish"> <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbrequest> <mrbrequest>
skipping to change at page 129, line 8 skipping to change at page 129, line 8
meeting the requirements. meeting the requirements.
However, unlike the Publishing interface, the Consumer interface is However, unlike the Publishing interface, the Consumer interface is
not specified as a Control Package. Rather, it is conceived as an not specified as a Control Package. Rather, it is conceived as an
XML-based protocol that can be transported by means of either HTTP or XML-based protocol that can be transported by means of either HTTP or
SIP, as will be shown in the following sections. SIP, as will be shown in the following sections.
As specified in [RFC6917], the Consumer interface can be involved in As specified in [RFC6917], the Consumer interface can be involved in
two topologies: Query mode and Inline mode. In the Query mode two topologies: Query mode and Inline mode. In the Query mode
(Section 7.2.1), the Consumer requests and responses are conveyed by (Section 7.2.1), the Consumer requests and responses are conveyed by
means of HTTP: once the AS gets the answer, the usual MEDIACTRL means of HTTP. Once the AS gets the answer, the usual MEDIACTRL
interactions occur between the AS and the MS chosen by the MRB. By interactions occur between the AS and the MS chosen by the MRB. By
contrast, in the Inline mode, the MRB is in the path between the AS contrast, in the Inline mode, the MRB is in the path between the AS
and the pool of MS it is handling. In this case, an AS can place and the pool of MS it is handling. In this case, an AS can place
Consumer requests using SIP as a transport, by means of a multipart Consumer requests using SIP as a transport, by means of a multipart
payload (Section 7.2.2) containing the Consumer request itself and an payload (Section 7.2.2) containing the Consumer request itself and an
SDP related either to the creation of a Control Channel or to a UAC SDP related either to the creation of a Control Channel or to a UAC
media dialog. This is called Inline-aware mode, since it assumes media dialog. This is called Inline-aware mode, since it assumes
that the interested AS knows that an MRB is in place and knows how to that the interested AS knows that an MRB is in place and knows how to
talk to it. The MRB is also conceived to work with AS that are talk to it. The MRB is also conceived to work with AS that are
unaware of its functionality, i.e., unaware of the Consumer unaware of its functionality, i.e., unaware of the Consumer
skipping to change at page 130, line 30 skipping to change at page 130, line 30
|<-+ with MS reported by MRB | |<-+ with MS reported by MRB |
| | | |
. . . .
. . . .
Figure 48: Media Resource Brokering: Query Mode Figure 48: Media Resource Brokering: Query Mode
In this example, the AS is interested in an MS meeting a defined set In this example, the AS is interested in an MS meeting a defined set
of requirements. The MS must: of requirements. The MS must:
1. support both the IVR and Mixer packages; 1. support both the IVR and Mixer packages.
2. provide at least 10 G.711 encoding/decoding RTP sessions for IVR 2. provide at least 10 G.711 encoding/decoding RTP sessions for IVR
purposes; purposes.
3. support HTTP-based streaming and support for the audio/x-wav file 3. support HTTP-based streaming and support for the audio/x-wav file
format in the IVR package. format in the IVR package.
These requirements are properly formatted according to the MRB These requirements are properly formatted according to the MRB
Consumer syntax. The framework transaction steps are as follows: Consumer syntax. The framework transaction steps are as follows:
o The AS sends an HTTP POST message to the MRB (1); the payload is, o The AS sends an HTTP POST message to the MRB (1). The payload is,
of course, the Consumer request, which is reflected by the of course, the Consumer request, which is reflected by the
Content-Type header (application/mrb-consumer+xml); the Consumer Content-Type header (application/mrb-consumer+xml). The Consumer
request (<mediaResourceRequest>, uniquely identified by its 'id' request (<mediaResourceRequest>, uniquely identified by its 'id'
attribute set to the random value 'n3un93wd'), includes some attribute set to the random value 'n3un93wd'), includes some
general requirements (<generalInfo>) and some IVR-specific general requirements (<generalInfo>) and some IVR-specific
requirements (<ivrInfo>); the general part of the requests requirements (<ivrInfo>). The general part of the requests
contains the set of required packages (<packages>); the IVR- contains the set of required packages (<packages>). The IVR-
specific section contains requirements concerning the number of specific section contains requirements concerning the number of
required IVR sessions (<ivr-sessions>), the file formats that are required IVR sessions (<ivr-sessions>), the file formats that are
to be supported (<file-formats>), and the required file transfer to be supported (<file-formats>), and the required file transfer
capabilities (<file-transfer-modes>); capabilities (<file-transfer-modes>).
o The MRB gets the request and parses it; then, according to its o The MRB gets the request and parses it. Then, according to its
business logic, it realizes it can't find a single MS capable of business logic, it realizes it can't find a single MS capable of
targeting the request and as a consequence picks two MS instances targeting the request and as a consequence picks two MS instances
that can handle 60 and 40 of the requested sessions, respectively; that can handle 60 and 40 of the requested sessions, respectively.
it prepares a Consumer response (2) to provide the AS with the It prepares a Consumer response (2) to provide the AS with the
requested information; the response (<mediaResourceResponse>, requested information. The response (<mediaResourceResponse>,
which includes the same 'id' attribute as the request) indicates which includes the same 'id' attribute as the request) indicates
success (status=200) and includes the relevant information success (status=200) and includes the relevant information
(<response-session-info>); specifically, the response includes (<response-session-info>). Specifically, the response includes
transaction-related information (the same session-id and seq transaction-related information (the same session-id and seq
provided by the AS in its request, to allow proper request/ provided by the AS in its request, to allow proper request/
response matching) together with information on the duration of response matching) together with information on the duration of
the reservation (expires=3600, i.e., after an hour the request the reservation (expires=3600, i.e., after an hour the request
will expire) and the SIP addresses of the chosen MS. will expire) and the SIP addresses of the chosen MS.
Note how the sequence number the MRB returned is not 1: according to Note how the sequence number the MRB returned is not 1. According to
the MRB specification, this is the starting value to increment for the MRB specification, this is the starting value to increment for
the sequence number to be used in subsequent requests. This means the sequence number to be used in subsequent requests. This means
that should the AS want to update or remove the session it should use that should the AS want to update or remove the session it should use
10 as a value for the sequence number in the related request. 10 as a value for the sequence number in the related request.
According to Section 12 of [RFC6917], this random value for the first According to Section 12 of [RFC6917], this random value for the first
sequence number is also a way to help prevent a malicious entity from sequence number is also a way to help prevent a malicious entity from
messing with or disrupting another AS session with the MRB. In fact, messing with or disrupting another AS session with the MRB. In fact,
sequence numbers in requests and responses have to match, and failure sequence numbers in requests and responses have to match, and failure
to provide the correct sequence number would result in session to provide the correct sequence number would result in session
failure and a 405 error message. failure and a 405 error message.
skipping to change at page 133, line 16 skipping to change at page 133, line 16
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
</response-session-info> </response-session-info>
</mediaResourceResponse> </mediaResourceResponse>
</mrbconsumer> </mrbconsumer>
For the sake of conciseness, the subsequent steps are not presented. For the sake of conciseness, the subsequent steps are not presented.
They are very trivial, since they basically consist of the AS issuing They are very trivial, since they basically consist of the AS issuing
a COMEDIA negotiation with either of the obtained MS, as already a COMEDIA negotiation with either of the obtained MS, as already
presented in Section 5. The same can be said with respect to presented in Section 5. The same can be said with respect to
attaching UAC media dialogs: in fact, since after the Query the attaching UAC media dialogs. In fact, since after the Query the
AS<->MS interaction becomes 1:1, UAC media dialogs can be redirected AS<->MS interaction becomes 1:1, UAC media dialogs can be redirected
directly to the proper MS using the 3PCC approach, e.g., as shown in directly to the proper MS using the 3PCC approach, e.g., as shown in
Figure 10. Figure 10.
7.2.2. Inline-Aware Mode 7.2.2. Inline-Aware Mode
Unlike the Query mode, in the Inline-Aware MRB Mode (IAMM) the AS Unlike the Query mode, in the Inline-Aware MRB Mode (IAMM) the AS
sends Consumer requests by means of SIP. Of course, saying that the sends Consumer requests by means of SIP. Of course, saying that the
transport changes from HTTP to SIP is not as trivial as it seems. In transport changes from HTTP to SIP is not as trivial as it seems. In
fact, HTTP and SIP behave in very different ways, and this is fact, HTTP and SIP behave in very different ways, and this is
reflected in the way the Inline-aware mode is conceived. reflected in the way the Inline-aware mode is conceived.
An AS willing to issue a Consumer request by means of SIP has to do An AS willing to issue a Consumer request by means of SIP has to do
so by means of an INVITE. As specified in [RFC6917], the payload of so by means of an INVITE. As specified in [RFC6917], the payload of
the INVITE can't contain only the Consumer request itself: in fact, the INVITE can't contain only the Consumer request itself. In fact,
the Consumer request is assumed to be carried within a SIP the Consumer request is assumed to be carried within a SIP
transaction. A Consumer session is not strictly associated with the transaction. A Consumer session is not strictly associated with the
lifetime of any SIP transaction, meaning that Consumer requests lifetime of any SIP transaction, meaning that Consumer requests
belonging to the same session may be transported over different SIP belonging to the same session may be transported over different SIP
messages; therefore, a hangup on any of these SIP dialogs would not messages; therefore, a hangup on any of these SIP dialogs would not
affect a Consumer session. affect a Consumer session.
That said, as documented in [RFC6230], [RFC6917] envisages two kinds That said, as documented in [RFC6230], [RFC6917] envisages two kinds
of SIP dialogs over which a Consumer request may be sent: a SIP of SIP dialogs over which a Consumer request may be sent: a SIP
control dialog (a SIP dialog sent by the AS in order to set up a control dialog (a SIP dialog sent by the AS in order to set up a
skipping to change at page 138, line 32 skipping to change at page 138, line 32
</rtp-codec> </rtp-codec>
</ivr-sessions> </ivr-sessions>
</media-server-address> </media-server-address>
</response-session-info> </response-session-info>
</mediaResourceResponse> </mediaResourceResponse>
</mrbconsumer> </mrbconsumer>
--Part --Part
The sequence diagram and the dumps effectively show the different The sequence diagram and the dumps effectively show the different
approach with respect to the Query mode: the SIP INVITE sent by the approach with respect to the Query mode. The SIP INVITE sent by the
AS (1.) includes both a Consumer request (the same as before) and an AS (1.) includes both a Consumer request (the same as before) and an
SDP to negotiate a CFW channel with an MS. The MRB takes care of the SDP to negotiate a CFW channel with an MS. The MRB takes care of the
request exactly as before (provisioning two MS instances) but with a request exactly as before (provisioning two MS instances) but with a
remarkable difference: first of all, it picks one of the two MS remarkable difference: first of all, it picks one of the two MS
instances on behalf of the AS (negotiating the Control Channel in instances on behalf of the AS (negotiating the Control Channel in
steps 3 to 6) and only then replies to the AS with both the MS side steps 3 to 6) and only then replies to the AS with both the MS side
of the SDP negotiation (with information on how to set up the Control of the SDP negotiation (with information on how to set up the Control
Channel) and the Consumer response itself. Channel) and the Consumer response itself.
The Consumer response is also slightly different in the first place: The Consumer response is also slightly different in the first place.
in fact, as can be seen in 7., there's an additional element In fact, as can be seen in 7., there's an additional element
(<connection-id>) that the MRB has added to the message. This (<connection-id>) that the MRB has added to the message. This
element contains the 'connection-id' that the AS and MS would have element contains the 'connection-id' that the AS and MS would have
built out of the 'From' and 'To' tags as explained in Section 6, had built out of the 'From' and 'To' tags as explained in Section 6, had
the AS contacted the MS directly: since the MRB has actually done the the AS contacted the MS directly. Since the MRB has actually done
negotiation on behalf of the AS, without this information the AS and the negotiation on behalf of the AS, without this information the AS
MS would refer to different connectionid attributes to target the and MS would refer to different connectionid attributes to target the
same dialog, thus causing the CFW protocol not to behave as expected. same dialog, thus causing the CFW protocol not to behave as expected.
This aspect will be more carefully described in the next section (for This aspect will be more carefully described in the next section (for
the media dialog-based approach), since the 'connection-id' attribute the media dialog-based approach), since the 'connection-id' attribute
is strictly related to media sessions. is strictly related to media sessions.
As before, for the sake of conciseness the subsequent steps of the As before, for the sake of conciseness the subsequent steps of the
previous transaction are quite trivial and therefore are not previous transaction are quite trivial and therefore are not
presented. In fact, as shown in the flow, the SIP negotiation has presented. In fact, as shown in the flow, the SIP negotiation has
resulted in both the AS and the chosen MS negotiating a Control resulted in both the AS and the chosen MS negotiating a Control
Channel. This means that the AS is only left to instantiate the Channel. This means that the AS is only left to instantiate the
skipping to change at page 146, line 25 skipping to change at page 146, line 25
The first obvious difference is that the first INVITE (1.) is not The first obvious difference is that the first INVITE (1.) is not
originated by the AS itself (the AS was willing to set up a Control originated by the AS itself (the AS was willing to set up a Control
Channel in the previous example) but by an authorized UAC (e.g., to Channel in the previous example) but by an authorized UAC (e.g., to
take advantage of a media service provided by the AS). As such, the take advantage of a media service provided by the AS). As such, the
first INVITE only contains an SDP to negotiate an audio and video first INVITE only contains an SDP to negotiate an audio and video
channel. The AS in its business logic needs to attach this UAC to an channel. The AS in its business logic needs to attach this UAC to an
MS according to some specific requirements (e.g., the called URI is MS according to some specific requirements (e.g., the called URI is
associated to a specific service) and as such prepares a Consumer associated to a specific service) and as such prepares a Consumer
request to be sent to the MRB in order to obtain a valid MS for that request to be sent to the MRB in order to obtain a valid MS for that
purpose: as before, the Consumer request is sent together with the purpose. As before, the Consumer request is sent together with the
SDP to the MRB (3.). The MRB extracts the Consumer payload and takes SDP to the MRB (3.). The MRB extracts the Consumer payload and takes
care of it as usual: it picks two MS instances and attaches the UAC care of it as usual; it picks two MS instances and attaches the UAC
to the first MS instance (5.). Once the MS has successfully to the first MS instance (5.). Once the MS has successfully
negotiated the audio and video streams (7.), the MRB takes note of negotiated the audio and video streams (7.), the MRB takes note of
the 'connection-id' associated with this call (which will be needed the 'connection-id' associated with this call (which will be needed
afterwards in order to manipulate the audio and video streams for afterwards in order to manipulate the audio and video streams for
this user) and sends back to the AS both the SDP returned by the MS this user) and sends back to the AS both the SDP returned by the MS
and the Consumer response (9.). The AS extracts the Consumer and the Consumer response (9.). The AS extracts the Consumer
response and takes note of both the MS instances it has been given response and takes note of both the MS instances it has been given
and the connection-id information. It then completes the scenario by and the connection-id information. It then completes the scenario by
sending back to the UAC the SDP returned by the MS (11.). sending back to the UAC the SDP returned by the MS (11.).
At this point, the UAC has successfully been attached to an MS. The At this point, the UAC has successfully been attached to an MS. The
AS only needs to set up a Control Channel to that MS, if needed; this AS only needs to set up a Control Channel to that MS, if needed.
step may not be required, especially if the Consumer request is an This step may not be required, especially if the Consumer request is
update to an existing session rather than the preparation of a new an update to an existing session rather than the preparation of a new
session. Assuming that a Control Channel towards that MS doesn't session. Assuming that a Control Channel towards that MS doesn't
exist yet, the AS creates it as usual by sending an INVITE directly exist yet, the AS creates it as usual by sending an INVITE directly
to the MS for which it has an address. Once done with that, it can to the MS for which it has an address. Once done with that, it can
start manipulating the audio and video streams of the UAC: to do so, start manipulating the audio and video streams of the UAC. To do so,
it refers to the <connection-id> element as reported by the MRB, it refers to the <connection-id> element as reported by the MRB,
rather than relying on the <connection-id> element that it is aware rather than relying on the <connection-id> element that it is aware
of. In fact, the AS is aware of a connection-id value (fd4fush5: of. In fact, the AS is aware of a connection-id value (fd4fush5:
117652221, built out of the messages exchanged with the MRB), while 117652221, built out of the messages exchanged with the MRB), while
the MS is aware of another (32pbdxZ8:KQw677BF, built out of the the MS is aware of another (32pbdxZ8:KQw677BF, built out of the
MRB-MS interaction). The right connection-id is of course the one MRB-MS interaction). The right connection-id is of course the one
the MS is aware of, and as such the AS refers to that connection-id, the MS is aware of, and as such the AS refers to that connection-id,
which the MRB added to the Consumer response just for that purpose. which the MRB added to the Consumer response just for that purpose.
7.2.3. Inline-Unaware Mode 7.2.3. Inline-Unaware Mode
skipping to change at page 149, line 15 skipping to change at page 149, line 15
No content for the presented messages is provided in this section, as No content for the presented messages is provided in this section, as
in the IUMM mode no Consumer transaction is involved. In this in the IUMM mode no Consumer transaction is involved. In this
example, a simple [RFC6230] Control Channel negotiation occurs where example, a simple [RFC6230] Control Channel negotiation occurs where
the MRB acts as an intermediary, that is, picking an MS for the AS the MRB acts as an intermediary, that is, picking an MS for the AS
according to some logic. In this case, in fact, the AS does not according to some logic. In this case, in fact, the AS does not
support the MRB specification and so just tries to set up a Control support the MRB specification and so just tries to set up a Control
Channel according to its own logic. Channel according to its own logic.
It is worth pointing out that the MRB may actually enforce its It is worth pointing out that the MRB may actually enforce its
decision about the MS to grant to the AS in different ways: decision about the MS to grant to the AS in different ways.
specifically, the sentence "redirect the INVITE" that is used in Specifically, the sentence "redirect the INVITE" that is used in
Figure 51 does not necessarily mean that a SIP 302 message should be Figure 51 does not necessarily mean that a SIP 302 message should be
used for that purpose. A simple way to achieve this may be used for that purpose. A simple way to achieve this may be
provisioning the unaware AS with different URIs, all actually provisioning the unaware AS with different URIs, all actually
transparently handled by the MRB itself: this would allow the MRB to transparently handled by the MRB itself; this would allow the MRB to
simply map those URIs to different MS instances. The SIP 'Contact' simply map those URIs to different MS instances. The SIP 'Contact'
header may also be used by the MRB in a reply to an INVITE coming header may also be used by the MRB in a reply to an INVITE coming
from an AS to provide the actual URI on which the chosen MS might be from an AS to provide the actual URI on which the chosen MS might be
reached. A motivation for such a discussion, and more details on reached. A motivation for such a discussion, and more details on
this topic, are provided in Section 7.3.2. this topic, are provided in Section 7.3.2.
7.3. Handling Media Dialogs 7.3. Handling Media Dialogs
It is worthwhile to briefly address how media dialogs would be It is worthwhile to briefly address how media dialogs would be
managed whenever an MRB is involved in the following scenarios. In managed whenever an MRB is involved in the following scenarios. In
skipping to change at page 150, line 30 skipping to change at page 150, line 30
| |-------------------------------------------------->| | |-------------------------------------------------->|
| | | | | | | |
|<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | | | | | |
. . . . . . . .
. . . . . . . .
Figure 52: Handling Media Dialogs in Query/IAMM Figure 52: Handling Media Dialogs in Query/IAMM
As can be deduced from the diagram, the interactions among the As can be deduced from the diagram, the interactions among the
components are quite straightforward: the AS knows which MS it has components are quite straightforward. The AS knows which MS it has
been assigned to (as a consequence of the MRB Consumer request, been assigned to (as a consequence of the MRB Consumer request,
whether it has been achieved by means of HTTP or SIP), and so it can whether it has been achieved by means of HTTP or SIP), and so it can
easily attach any UAC accessing its functionality to the MS itself easily attach any UAC accessing its functionality to the MS itself
and manipulate its media connections by using the CFW Control Channel and manipulate its media connections by using the CFW Control Channel
as usual. as usual.
In such a scenario, the MRB is only involved as a locator. Once the In such a scenario, the MRB is only involved as a locator. Once the
MRB provides the AS with the URI of the required resource, it doesn't MRB provides the AS with the URI of the required resource, it doesn't
interfere with subsequent interactions unless it wants to perform interfere with subsequent interactions unless it wants to perform
monitoring (e.g., by exploiting the Publishing information reported monitoring (e.g., by exploiting the Publishing information reported
by the MS). As a consequence, the scenario basically becomes 1:1 by the MS). As a consequence, the scenario basically becomes 1:1
between the AS and the MS again. between the AS and the MS again.
Nevertheless, there are cases when having an MRB in the SIP signaling Nevertheless, there are cases when having an MRB in the SIP signaling
path as well might be a desired feature: e.g., for more control over path as well might be a desired feature, e.g., for more control over
the use of the resources. Considering how the Consumer interface has the use of the resources. Considering how the Consumer interface has
been envisaged, this feature is easily achievable, with no change to been envisaged, this feature is easily achievable, with no change to
the protocol required at all. Specifically, in order to achieve such the protocol required at all. Specifically, in order to achieve such
functionality, the MRB may reply to a Consumer request with a URI for functionality, the MRB may reply to a Consumer request with a URI for
which the MRB is responsible (rather than the MS SIP URI as discussed which the MRB is responsible (rather than the MS SIP URI as discussed
previously) and map this URI to the actual MS URI in its business previously) and map this URI to the actual MS URI in its business
logic; this would be transparent to the AS. This way, the AS would logic; this would be transparent to the AS. This way, the AS would
interact with the MRB as if it were the MS itself. interact with the MRB as if it were the MS itself.
Figure 53 shows how the scenario would change in this case. Figure 53 shows how the scenario would change in this case.
skipping to change at page 151, line 43 skipping to change at page 151, line 43
Figure 53: Handling Media Dialogs in Query/IAMM: MRB in the Signaling Figure 53: Handling Media Dialogs in Query/IAMM: MRB in the Signaling
Path Path
This time, even though the MRB has picked a specific MS after a This time, even though the MRB has picked a specific MS after a
request from an AS, it replies with another SIP URI, a URI it would request from an AS, it replies with another SIP URI, a URI it would
reply to itself. The AS would contact that URI in order to negotiate reply to itself. The AS would contact that URI in order to negotiate
the Control Channel, and the MRB would proxy/forward the request to the Control Channel, and the MRB would proxy/forward the request to
the actual MS transparently. Eventually, the Control Channel would the actual MS transparently. Eventually, the Control Channel would
be instantiated between the AS and the MS. The same happens for UACs be instantiated between the AS and the MS. The same happens for UACs
handled by the AS: the AS would forward the calls to the URI provided handled by the AS; the AS would forward the calls to the URI provided
to it, the one handled by the MRB, which would in turn relay the call to it, the one handled by the MRB, which would in turn relay the call
to the MS in order to have the proper RTP channels created between to the MS in order to have the proper RTP channels created between
the UAC and the MS. the UAC and the MS.
This scenario is not very different from the previous scenario, This scenario is not very different from the previous scenario,
except that the MRB is now on the signaling path for both the SIP except that the MRB is now on the signaling path for both the SIP
control dialog and the SIP media dialogs, allowing it to have more control dialog and the SIP media dialogs, allowing it to have more
control of the resources (e.g., triggering a BYE if a resource has control of the resources (e.g., triggering a BYE if a resource has
expired). There are several possible approaches an MRB might take to expired). There are several possible approaches an MRB might take to
allocate URIs to map to a requested MS. For example, an MRB might allocate URIs to map to a requested MS. For example, an MRB might
skipping to change at page 152, line 35 skipping to change at page 152, line 35
media dialog management. In fact, in the MRB-unaware mode, there media dialog management. In fact, in the MRB-unaware mode, there
would be no Consumer request, and an AS would actually see the MRB as would be no Consumer request, and an AS would actually see the MRB as
an MS. Unlike the previous scenarios, because there is no AS<->MRB an MS. Unlike the previous scenarios, because there is no AS<->MRB
interaction and as such no MS selection process, the MRB would likely interaction and as such no MS selection process, the MRB would likely
be in the signaling path anyway, at least when the AS first shows up. be in the signaling path anyway, at least when the AS first shows up.
The MRB could either redirect the AS to an MS directly or The MRB could either redirect the AS to an MS directly or
transparently act as a Proxy/B2BUA and contact an MS (according to transparently act as a Proxy/B2BUA and contact an MS (according to
implementation-specific policies) on behalf of the unaware AS. implementation-specific policies) on behalf of the unaware AS.
While apparently not a problem, this raises an issue when the same While apparently not a problem, this raises an issue when the same
unaware AS has several sessions with different MS: the AS would only unaware AS has several sessions with different MS. The AS would only
see one "virtual" MS (the MRB), and so it would relay all calls see one "virtual" MS (the MRB), and so it would relay all calls
there, making it hard for the MRB to understand where these media there, making it hard for the MRB to understand where these media
dialogs should belong: specifically, whether the UAC calling belongs dialogs should belong: specifically, whether the UAC calling belongs
to the AS application logic leading to MS1 or MS2, or somewhere else. to the AS application logic leading to MS1 or MS2, or somewhere else.
One possible, and very simple, approach to take care of this issue is One possible, and very simple, approach to take care of this issue is
to always relay the SIP dialogs from the same unaware AS to the same to always relay the SIP dialogs from the same unaware AS to the same
MS, as depicted in Figure 54. MS, as depicted in Figure 54.
UAC1 UAC2 AS MRB MS UAC1 UAC2 AS MRB MS
skipping to change at page 153, line 46 skipping to change at page 153, line 46
| | | | | | | | | |
| |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
| | | | | | | | | |
. . . . . . . . . .
. . . . . . . . . .
Figure 54: Handling Media Dialogs in IUMM: Always the Same MS Figure 54: Handling Media Dialogs in IUMM: Always the Same MS
In this example, the AS creates two different Control Channel In this example, the AS creates two different Control Channel
sessions (A and B) to address two different business logic sessions (A and B) to address two different business logic
implementations: e.g., the AS SIP URI 'xyz' (associated with CFW implementations; e.g., the AS SIP URI 'xyz' (associated with CFW
session A) may be an IVR pizza-ordering application, while the AS SIP session A) may be an IVR pizza-ordering application, while the AS SIP
URI 'jkl' (associated with CFW session B) may be associated with a URI 'jkl' (associated with CFW session B) may be associated with a
conference room. It's quite clear, then, that if the MRB forwarded conference room. It's quite clear, then, that if the MRB forwarded
the two CFW sessions to two different MS, the handling of UAC media the two CFW sessions to two different MS, the handling of UAC media
dialogs would prove troublesome, because the MRB would have dialogs would prove troublesome, because the MRB would have
difficulty figuring out whether UAC1 should be attached to the MS difficulty figuring out whether UAC1 should be attached to the MS
managing CFW session A or the MS managing CFW session B. In this managing CFW session A or the MS managing CFW session B. In this
example, forwarding all CFW sessions and UAC media dialogs coming example, forwarding all CFW sessions and UAC media dialogs coming
from the same MRB-unaware AS to the same MS would work as expected: from the same MRB-unaware AS to the same MS would work as expected.
the MRB would in fact leave the mapping of media dialogs and CFW The MRB would in fact leave the mapping of media dialogs and CFW
sessions up to the AS. sessions up to the AS.
This approach, while very simple and indeed not very scalable, would This approach, while very simple and indeed not very scalable, would
actually help take care of the issue: in fact, no matter how many actually help take care of the issue. In fact, no matter how many
separate Control Channels the AS might have with the MRB/MS (in this separate Control Channels the AS might have with the MRB/MS (in this
example, Control Channel A would be mapped to application xyz and example, Control Channel A would be mapped to application xyz and
Control Channel B to application jkl), the termination point would Control Channel B to application jkl), the termination point would
still always be the same MS, which would consequently be the still always be the same MS, which would consequently be the
destination for all media dialogs as well. destination for all media dialogs as well.
To overcome the scalability limitations of such an approach, at least To overcome the scalability limitations of such an approach, at least
in regard to the MRB being in the SIP signaling path for all calls, a in regard to the MRB being in the SIP signaling path for all calls, a
different approach needs to be exploited. In fact, especially in the different approach needs to be exploited. In fact, especially in the
case of different applications handled by the same unaware AS, it case of different applications handled by the same unaware AS, it
skipping to change at page 158, line 16 skipping to change at page 158, line 16
In this new example, we still assume that the same unaware AS is In this new example, we still assume that the same unaware AS is
handling two different applications, still associated with the same handling two different applications, still associated with the same
URIs as before. This time, though, we also assume that the AS has URIs as before. This time, though, we also assume that the AS has
been designed to try to use different MS instances to handle the two been designed to try to use different MS instances to handle the two
very different applications for which it is responsible. We also very different applications for which it is responsible. We also
assume that it has been configured to be able to use two different MS assume that it has been configured to be able to use two different MS
instances, reachable at SIP URI 'fake-ms1' and 'fake-ms2', instances, reachable at SIP URI 'fake-ms1' and 'fake-ms2',
respectively, and both actually handled by the MRB transparently. respectively, and both actually handled by the MRB transparently.
This results, just as before, in two different Control Channels (A This results, just as before, in two different Control Channels (A
and B) being created, but this time towards two different MS: and B) being created, but this time towards two different MS.
specifically, the MRB makes sure that for this AS the Control Channel Specifically, the MRB makes sure that for this AS the Control Channel
negotiation towards 'fake-ms1' is actually redirected to MS1; at the negotiation towards 'fake-ms1' is actually redirected to MS1. At the
same time, 'fake-ms2' is associated with MS2. Once the AS has set up same time, 'fake-ms2' is associated with MS2. Once the AS has set up
the Control Channels with both of the MS, it is ready to handle media the Control Channels with both of the MS, it is ready to handle media
dialogs. UAC1 calls the SIP URI 'xyz' on the AS to order a pizza. dialogs. UAC1 calls the SIP URI 'xyz' on the AS to order a pizza.
The AS attaches the media dialog to the MS it knows is responsible The AS attaches the media dialog to the MS it knows is responsible
for that branch of application logic, i.e., 'fake-ms1'; the MRB in for that branch of application logic, i.e., 'fake-ms1'. The MRB in
turn makes sure that it reaches the right MS instance, MS1. Later turn makes sure that it reaches the right MS instance, MS1. Later
on, a different user, UAC2, calls SIP URI 'jkl' to join a conference on, a different user, UAC2, calls SIP URI 'jkl' to join a conference
room. This time, the AS attaches this new media dialog to the MS room. This time, the AS attaches this new media dialog to the MS
instance handling the conference application, i.e., 'fake-ms2'; instance handling the conference application, i.e., 'fake-ms2'.
again, the MRB makes sure that it is actually MS2 that receives the Again, the MRB makes sure that it is actually MS2 that receives the
dialog. dialog.
Again, this diagram is only meant to describe how the MRB might Again, this diagram is only meant to describe how the MRB might
enforce its decisions. Just as described in the previous examples, enforce its decisions. Just as described in the previous examples,
the MRB may choose to either act as a Proxy/B2BUA between the AS and the MRB may choose to either act as a Proxy/B2BUA between the AS and
the MS instances or redirect the AS to the right MS instances when the MS instances or redirect the AS to the right MS instances when
they're first contacted (e.g., by means of the Contact header and/or they're first contacted (e.g., by means of the Contact header and/or
a SIP redirect, as explained before) and let the AS attach the media a SIP redirect, as explained before) and let the AS attach the media
dialogs by itself. dialogs by itself.
skipping to change at page 162, line 12 skipping to change at page 162, line 12
Sections 5.1 and 5.2, an AS and an MS negotiate a cfw-id attribute in Sections 5.1 and 5.2, an AS and an MS negotiate a cfw-id attribute in
the SDP, and the same value is subsequently used in the SYNC message the SDP, and the same value is subsequently used in the SYNC message
on the Control Channel that is created after the negotiation, thus on the Control Channel that is created after the negotiation, thus
reassuring both the AS and the MS that the Control Channel they share reassuring both the AS and the MS that the Control Channel they share
is in fact the channel they negotiated in the first place. is in fact the channel they negotiated in the first place.
Let's also assume that AS1 has created a conference mix Let's also assume that AS1 has created a conference mix
(confid=74b6d62) to which it has attached some participants within (confid=74b6d62) to which it has attached some participants within
the context of its business logic, while AS2 has created a currently the context of its business logic, while AS2 has created a currently
active IVR dialog (dialogid=dfg3252) with a user agent it is handling active IVR dialog (dialogid=dfg3252) with a user agent it is handling
(237430727:a338e95f); AS2 has also joined two connections to each (237430727:a338e95f). AS2 has also joined two connections to each
other (1:75d4dd0d and 1:b9e6a659). Clearly, it is highly desirable other (1:75d4dd0d and 1:b9e6a659). Clearly, it is highly desirable
that AS1 not be aware of what AS2 is doing with the MS and vice that AS1 not be aware of what AS2 is doing with the MS and vice
versa, and that they not be allowed to manipulate each other's versa, and that they not be allowed to manipulate each other's
resources. The following transactions will occur: resources. The following transactions will occur:
1. AS1 places a generic audit request to both the Mixer and IVR 1. AS1 places a generic audit request to both the Mixer and IVR
packages; packages.
2. AS2 places a generic audit request to both the Mixer and IVR 2. AS2 places a generic audit request to both the Mixer and IVR
packages; packages.
3. AS1 tries to terminate the dialog created by AS2 (6791fee); 3. AS1 tries to terminate the dialog created by AS2 (6791fee).
4. AS2 tries to join a user agent it handles (1:272e9c05) to the 4. AS2 tries to join a user agent it handles (1:272e9c05) to the
conference mix created by AS1 (74b6d62). conference mix created by AS1 (74b6d62).
A sequence diagram of the above-mentioned transactions is depicted in A sequence diagram of the above-mentioned transactions is depicted in
Figure 59, which shows how the MS is assumed to reply in all cases, Figure 59, which shows how the MS is assumed to reply in all cases,
in order to avoid security issues: in order to avoid security issues:
AS1 AS2 MS AS1 AS2 MS
| | | | | |
skipping to change at page 163, line 50 skipping to change at page 163, line 50
Figure 59: Security Considerations: Framework Transaction Figure 59: Security Considerations: Framework Transaction
The expected outcome of the transaction is that the MS partially The expected outcome of the transaction is that the MS partially
"lies" to both AS1 and AS2 when replying to the audit requests (not "lies" to both AS1 and AS2 when replying to the audit requests (not
all of the identifiers are reported, but only those identifiers with all of the identifiers are reported, but only those identifiers with
which each AS is directly involved), and the MS denies the requests which each AS is directly involved), and the MS denies the requests
for the unauthorized operations (403). Looking at each transaction for the unauthorized operations (403). Looking at each transaction
separately: separately:
o In the first transaction (A1), AS1 places a generic <audit> o In the first transaction (A1), AS1 places a generic <audit>
request to the IVR package; the request is generic, since no request to the IVR package. The request is generic, since no
attributes are passed as part of the request, meaning that AS1 is attributes are passed as part of the request, meaning that AS1 is
interested in the MS capabilities as well as all of the dialogs interested in the MS capabilities as well as all of the dialogs
that the MS is currently handling; as can be seen in the reply that the MS is currently handling. As can be seen in the reply
(A2), the MS only reports in the <auditresponse> the package (A2), the MS only reports in the <auditresponse> the package
capabilities, while the <dialogs> element is empty; this is capabilities, while the <dialogs> element is empty; this is
because the only dialog the MS is handling has actually been because the only dialog the MS is handling has actually been
created by AS2, which causes the MS not to report the related created by AS2, which causes the MS not to report the related
identifier (6791fee) to AS1; in fact, AS1 could use that identifier (6791fee) to AS1. In fact, AS1 could use that
identifier to manipulate the dialog, e.g., by tearing it down and identifier to manipulate the dialog, e.g., by tearing it down and
thus causing the service to be interrupted without AS2's thus causing the service to be interrupted without AS2's
intervention; intervention.
o In the second transaction (B1), AS1 places an identical <audit> o In the second transaction (B1), AS1 places an identical <audit>
request to the Mixer package; the request is again generic, request to the Mixer package. The request is again generic,
meaning that AS1 is interested in the package capabilities as well meaning that AS1 is interested in the package capabilities as well
as all the mixers and connections that the package is handling at as all the mixers and connections that the package is handling at
the moment; this time, the MS reports not only capabilities (B2) the moment. This time, the MS reports not only capabilities (B2)
but information about mixers and connections as well; however, but information about mixers and connections as well. However,
this information is not complete; in fact, only information about this information is not complete; in fact, only information about
mixers and connections originated by AS1 are reported (mixer mixers and connections originated by AS1 are reported (mixer
74b6d62 and its participants), while those originated by AS2 are 74b6d62 and its participants), while those originated by AS2 are
omitted in the report; the motivation is the same as before; omitted in the report. The motivation is the same as before.
o In the third and fourth transactions (C1 and D1), it's AS2 that o In the third and fourth transactions (C1 and D1), it's AS2 that
places an <audit> request to both the IVR and Mixer packages; as places an <audit> request to both the IVR and Mixer packages. As
with the previous transactions, the audit requests are generic; with the previous transactions, the audit requests are generic.
looking at the replies (C2 and D2), it's obvious that the Looking at the replies (C2 and D2), it's obvious that the
capabilities section is identical to the replies given to AS1; in capabilities section is identical to the replies given to AS1. In
fact, the MS has no reason to "lie" about what it can do; the fact, the MS has no reason to "lie" about what it can do. The
<dialogs> and <mixers> sections are totally different; AS2 in fact <dialogs> and <mixers> sections are totally different. AS2 in
receives information about its own IVR dialog (6791fee), which was fact receives information about its own IVR dialog (6791fee),
omitted in the reply to AS1, while it only receives information which was omitted in the reply to AS1, while it only receives
about the only connection it created (1:75d4dd0d and 1:b9e6a659) information about the only connection it created (1:75d4dd0d and
without any details related to the mixers and connections 1:b9e6a659) without any details related to the mixers and
originated by AS1; connections originated by AS1.
o In the fifth transaction (E1), AS1, instead of just auditing the o In the fifth transaction (E1), AS1, instead of just auditing the
packages, tries to terminate (<dialogterminate>) the dialog packages, tries to terminate (<dialogterminate>) the dialog
created by AS2 (6791fee); since the identifier has not been created by AS2 (6791fee). Since the identifier has not been
reported by the MS in the reply to the previous audit request, we reported by the MS in the reply to the previous audit request, we
assume that AS1 accessed it via a different out-of-band mechanism. assume that AS1 accessed it via a different out-of-band mechanism.
This is assumed to be an unauthorized operation, because the This is assumed to be an unauthorized operation, because the
above-mentioned dialog is outside the bounds of AS1; therefore, above-mentioned dialog is outside the bounds of AS1; therefore,
the MS, instead of handling the syntactically correct request, the MS, instead of handling the syntactically correct request,
replies (E2) with a framework-level 403 message (Forbidden), replies (E2) with a framework-level 403 message (Forbidden),
leaving the dialog untouched; leaving the dialog untouched.
o Similarly, in the sixth and last transaction (F1), AS2 tries to o Similarly, in the sixth and last transaction (F1), AS2 tries to
attach (<join>) one of the UACs it is handling to the conference attach (<join>) one of the UACs it is handling to the conference
mix created by AS1 (74b6d62); just as in the previous transaction, mix created by AS1 (74b6d62). Just as in the previous
the identifier is assumed to have been accessed by AS2 via some transaction, the identifier is assumed to have been accessed by
out-of-band mechanism, since the MS didn't report it in the reply AS2 via some out-of-band mechanism, since the MS didn't report it
to the previous audit request. While one of the identifiers (the in the reply to the previous audit request. While one of the
UAC) is actually handled by AS2, the other (the conference mix) is identifiers (the UAC) is actually handled by AS2, the other (the
not; therefore, as with the fifth transaction, this last conference mix) is not; therefore, as with the fifth transaction,
transaction is regarded by the MS as outside the bounds of AS2; this last transaction is regarded by the MS as outside the bounds
for the same reason as before, the MS replies (F2) with a of AS2. For the same reason as before, the MS replies (F2) with a
framework-level 403 message (Forbidden), leaving the mix and the framework-level 403 message (Forbidden), leaving the mix and the
UAC unjoined. UAC unjoined.
A1. AS1 -> MS (CFW CONTROL, audit IVR) A1. AS1 -> MS (CFW CONTROL, audit IVR)
-------------------------------------- --------------------------------------
CFW 140e0f763352 CONTROL CFW 140e0f763352 CONTROL
Control-Package: msc-ivr/1.0 Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml Content-Type: application/msc-ivr+xml
Content-Length: 81 Content-Length: 81
 End of changes. 243 change blocks. 
350 lines changed or deleted 351 lines changed or added

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