RFC 7058
Media Control Channel Framework (CFW) Call Flow Examples
Pages: 182
Informational
Informational
Part 1 of 6 – Pages 1 to 20
Internet Engineering Task Force (IETF) A. Amirante Request for Comments: 7058 University of Napoli Category: Informational T. Castaldi ISSN: 2070-1721 L. Miniero Meetecho S P. Romano University of Napoli November 2013 Media Control Channel Framework (CFW) Call Flow ExamplesAbstract
This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference document for both implementors and protocol researchers. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7058.
Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4 2. Conventions .....................................................5 3. Terminology .....................................................5 4. A Practical Approach ............................................6 4.1. State Diagrams .............................................6 5. Control Channel Establishment ..................................10 5.1. COMEDIA Negotiation .......................................11 5.2. SYNC ......................................................14 5.3. K-ALIVE ...................................................15 5.4. Wrong Behavior ............................................17 6. Use-Case Scenarios and Examples ................................20 6.1. Echo Test .................................................27 6.1.1. Direct Echo Test ...................................28 6.1.2. Echo Test Based on Recording .......................30 6.2. Phone Call ................................................39 6.2.1. Direct Connection ..................................42 6.2.2. Conference-Based Approach ..........................44 6.2.3. Recording a Conversation ...........................51 6.3. Conferencing ..............................................57 6.3.1. Simple Bridging ....................................62 6.3.2. Rich Conference Scenario ...........................66 6.3.3. Coaching Scenario ..................................75 6.3.4. Sidebars ...........................................83 6.3.5. Floor Control ......................................93 6.4. Additional Scenarios ......................................99 6.4.1. Voice Mail ........................................100 6.4.2. Current Time ......................................107 6.4.3. DTMF-Driven Conference Manipulation ...............112 7. Media Resource Brokering ......................................126 7.1. Publishing Interface .....................................127 7.2. Consumer Interface .......................................136 7.2.1. Query Mode ........................................137 7.2.2. Inline-Aware Mode .................................140 7.2.3. Inline-Unaware Mode ...............................155 7.3. Handling Media Dialogs ...................................157 7.3.1. Query and Inline-Aware Mode .......................157 7.3.2. Inline-Unaware Mode ...............................160 7.3.3. CFW Protocol Behavior .............................167 8. Security Considerations .......................................170 9. Acknowledgments ...............................................180 10. References ...................................................180 10.1. Normative References ....................................180 10.2. Informative References ..................................181
1. Introduction
This document provides a list of typical MEDIACTRL Media Control Channel Framework [RFC6230] call flows. The motivation for this comes from our implementation experience with the framework and its protocol. This drove us to write a simple guide to the use of the several interfaces between Application Servers and MEDIACTRL-based Media Servers, and a base reference document for other implementors and protocol researchers. Following this spirit, this document covers several aspects of the interaction between Application Servers and Media Servers. However, in the context of this document, the call flows almost always depict the interaction between a single Application Server (which, for the sake of conciseness, is called the AS from now on) and a single Media Server (MS). In Section 7, some flows involving more entities by means of a Media Resource Broker compliant with [RFC6917] are presented. To help readers understand all the flows (as related to both SIP dialogs and Media Control Channel Framework (CFW) transactions), the domains hosting the AS and the MS in all the scenarios are called 'as.example.com' and 'ms.example.net', respectively, per [RFC2606]. The flows will often focus more on the CFW [RFC6230] interaction, rather than on the other involved protocols, e.g., SIP [RFC3261], the Session Description Protocol (SDP) [RFC3264], or RTP [RFC3550]. In the next paragraphs, a brief overview of our implementation approach is described, with particular focus on protocol-related aspects. This involves state diagrams that depict both the client 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 implementation of the framework. It is only meant to help readers understand how the framework works from a practical point of view. Once done with these preliminary considerations, in the subsequent sections real-life scenarios are addressed. In this context, first of all, the establishment of the Control Channel is dealt with. After that, some use-case scenarios involving the most typical multimedia applications are depicted and described. 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 framework. The specifications are a mandatory read for all implementors, especially because this document follows their guidelines but does not delve into the details of every aspect of the protocol.
2. Conventions
Note that due to RFC formatting conventions, SIP/SDP and CFW lines whose content exceeds 72 characters are split across lines. This line folding is marked by a backslash at the end of the first line. This backslash, the preceding whitespace, the following CRLF, and the whitespace beginning the next line would not appear in the actual protocol contents. Note also that the indentation of the XML content is only provided for readability. Actual messages will follow strict XML syntax, which allows, but does not require, indentation. Due to the same limit of 72 characters per line, this document also sometimes splits the content of XML elements across lines. Please be aware that when this happens, no whitespace is actually meant to be at either the beginning or the end of the element content. 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 represent any transaction message but are rather meant as an indication to the reader that the involved network entity made a decision, within its application logic, according to the input it previously received.3. Terminology
This document uses the same terminology as [RFC6230], [RFC6231], [RFC6505], and [RFC6917]. The following terms are only a summarization of the terms most commonly used in this context and are mostly derived from the terminology used in the related documents: COMEDIA: connection-oriented media (i.e., TCP and Transport Layer Security (TLS)). Also used to signify the support in SDP for connection-oriented media and the RFCs that define that support ([RFC4145] and [RFC4572]). Application Server: an entity that requests media processing and manipulation from a Media Server; typical examples are Back-to- Back User Agents (B2BUAs) and endpoints requesting manipulation of a third party's media stream. Media Server: an entity that performs a service, such as media processing, on behalf of an Application Server; typical provided functions are mixing, announcement, tone detection and generation, and play and record services. Control Channel: a reliable connection between an Application Server and a Media Server that is used to exchange framework messages.
VCR controls: runtime control of aspects of an audio playback like
speed and volume, via dual-tone multi-frequency (DTMF) signals
sent by the user, in a manner that resembles the functions of a
VCR (video cassette recorder) controller.
4. A Practical Approach
In this document, we embrace an engineering approach to the
description of a number of interesting scenarios that can be realized
through the careful orchestration of the Media Control Channel
Framework entities, namely the Application Server and the Media
Server. We will demonstrate, through detailed call flows, how a
variegated bouquet of services (ranging from very simple scenarios to
much more complicated examples) can be implemented with the
functionality currently offered, within the main MEDIACTRL framework,
by the Control Packages that have been made available to date. The
document aims at being a useful guide for those interested in
investigating the inter-operation among MEDIACTRL components, as well
as being a base reference document for application developers willing
to build advanced services on top of the base infrastructure made
available by the framework.
4.1. State Diagrams
In this section, we present an "informal" view of the main MEDIACTRL
protocol interactions, in the form of state diagrams. Each diagram
is indeed a classical representation of a Mealy automaton, comprising
a number of possible protocol states, indicated with rectangular
boxes. Transitions between states are indicated through edges, with
each edge labeled with a slash-separated pair representing a specific
input together with the associated output (a dash in the output
position means that, for that particular input, no output is
generated from the automaton). Some of the inputs are associated
with MEDIACTRL protocol messages arriving at a MEDIACTRL component
while it is in a certain state. This is the case for 'CONTROL',
'REPORT' (in its various "flavors" -- pending, terminate, etc.),
'200', '202', and 'Error' (error messages correspond to specific
numeric codes). Further inputs represent triggers arriving at the
MEDIACTRL automaton from the upper layer, namely the Application
Programming Interface used by programmers while implementing
MEDIACTRL-enabled services. Such inputs have been indicated with the
term 'API' followed by the message that the API itself is triggering
(as an example, 'API terminate' is a request to send a 'REPORT'
message with a status of 'terminate' to the peering component).
Four diagrams are provided. Two of them (Figures 1 and 2) describe normal operation of the framework. Figure 3 contains two diagrams describing asynchronous event notifications. Figure 1 embraces the 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 issuing a CONTROL message addressed to the AS; events are acknowledged by the AS through standard 200 responses. Hence, the behavior of the AS, which mirrors that of the MS, is depicted in the lower part of the figure. Coming back to Figure 1, the diagram shows that the MS activates upon reception of CONTROL messages coming from the AS. The CONTROL messages instruct the MS regarding the execution of a specific command that belongs to one of the available Control Packages. The execution of the received command can either be quick or require some time. In the former case, right after completing its operation, the MS sends back to the AS a 200 message, which basically acknowledges correct termination of the invoked task. In the latter case, the MS first sends back an interlocutory 202 message containing a 'Timeout' 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 task does not complete in the provided timeout, the server will update the AS on the other side of the Control Channel by periodically issuing 'REPORT update' messages; each such message has 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 'REPORT terminate' message. The transaction is concluded when the AS acknowledges receipt of the message. It is worth pointing out that 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 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 final REPORT terminate request. Again, the behavior of the AS, as depicted in Figure 2, mirrors the above-described actions undertaken at the MS side. The figures also show the cases in which transactions cannot be successfully completed due to abnormal conditions; such conditions always trigger the creation and transmission of a specific 'Error' message that, as mentioned previously, is reported as a numeric error code.
+------------------+ CONTROL/- +------------------+ API 202/202 | Idle/'terminate' |------------>| CONTROL received |---------+ +------------------+ +------------------+ | ^ ^ ^ API 200/200 | | | | | | | | | | | +------------------+ | | | 200/- | API Error/Error | | | +----------------------------+ | | | +-------------+ | | Waiting for | v | last 200 |<------------------------+ +------------+ +-------------+ | | '202' sent | ^ | +------------+ | | | | | +---------------+ | | API terminate/ API terminate/ | | REPORT terminate REPORT terminate | | | +--------------------+ | | 'update' confirmed |------+ API update/ | +--------------------+ | REPORT update | ^ | API update/ | | | REPORT update | | v | | 200/- +---------------+ | +--------------| 'update' sent |<----------------+ +---------------+ Figure 1: Media Server CFW State Diagram
+--------------+ 202/- +--------------+ +-->| CONTROL sent |---------->| 202 received | | +--------------+ +--------------+ | | | | | | | | | | API CONTROL/ | | 200/- | | | send CONTROL | | | | | | | | Error/ | | +------------------+ | | Error | | | Idle/'terminate' |<-+ | | | +------------------+<---------+ | | ^ ^ | | | | REPORT 'terminate'/ | | | | send 200 | | | +--------------------------------+ | REPORT 'update'/ | | send 200 | REPORT 'terminate'/ | | send 200 | | +-----------+ | +---------------------| 'update ' |<--------------+ +-----------+ ^ | | | REPORT 'update'/ +------+ send 200 Figure 2: Application Server CFW State Diagram
+--------------+ +-->| CONTROL sent | | +--------------+ | | | | API CONTROL/ | | 200/- send CONTROL | | | | +------------------+ | | Idle/'terminate' |<----+ +------------------+ (Media Server perspective) +------------------+ CONTROL/- +------------------+ | Idle/'terminate' |------------>| CONTROL received | +------------------+ +------------------+ ^ API 200/200 | | | +----------------------------+ (Application Server perspective) Figure 3: Event Notifications5. Control Channel Establishment
As specified in [RFC6230], the preliminary step to any interaction between an AS and an MS is the establishment of a Control Channel between the two. As explained in the next subsection, this is accomplished by means of a connection-oriented media (COMEDIA) [RFC4145] [RFC4572] negotiation. This negotiation allows a reliable 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 / Stream Control Transmission Protocol (SCTP)) and whether any application-level security is needed or not (e.g., TLS). For the sake of simplicity, we assume that an unencrypted TCP connection is negotiated between the two involved entities. Once they have 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 is also presented in the following paragraphs. For the sake of completeness, this section also includes a couple of common mistakes that can occur when dealing with the Control Channel establishment.
AS MS | | | INVITE (COMEDIA) | |------------------------------>| | 100 (Trying) | |<------------------------------| | 200 OK (COMEDIA) | |<------------------------------| | ACK | |------------------------------>| | | |==============================>| | TCP CONNECT (CTRL CHANNEL) | |==============================>| | | | SYNC (Dialog-ID, etc.) | |+++++++++++++++++++++++++++++>>| | |--+ | | | Check SYNC | |<-+ | 200 OK | |<<+++++++++++++++++++++++++++++| | | . . . . Figure 4: Control Channel Establishment5.1. COMEDIA Negotiation
As a first step, the AS and the MS establish a Control SIP dialog. This is usually originated by the AS itself. The AS generates a SIP INVITE message containing in its SDP body information about the TCP connection it wants to establish with the MS. In the provided example (see Figure 5 and the attached call flow), the AS wants to actively open a new TCP connection, which on its side will be bound to port 5757. If the request is fine, the MS answers by communicating to the AS the transport address to connect to in order to establish the TCP connection. In the provided example, the MS will listen on port 7575. Once this negotiation is over, the AS can effectively connect to the MS. The negotiation includes additional attributes. The 'cfw-id' attribute is the most important, since it specifies the Dialog-ID, which in turn will be subsequently referred to by both the AS and the MS as specified in [RFC6230].
AS MS | | | 1. INVITE (COMEDIA) | |------------------------------>| | 2. 100 (Trying) | |<------------------------------| | 3. 200 OK (COMEDIA) | |<------------------------------| | 4. ACK | |------------------------------>| | | |==============================>| | TCP CONNECT (CTRL CHANNEL) | |==============================>| | | . . . . Figure 5: COMEDIA Negotiation: Sequence Diagram 1. AS -> MS (SIP INVITE) ------------------------ INVITE sip:MediaServer@ms.example.net:5060 SIP/2.0 Via: SIP/2.0/UDP 203.0.113.1:5060;\ branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060 Max-Forwards: 70 Contact: <sip:ApplicationServer@203.0.113.1:5060> To: <sip:MediaServer@ms.example.net:5060> From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63 Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER Content-Type: application/sdp Content-Length: 203 v=0 o=lminiero 2890844526 2890842807 IN IP4 as.example.com s=MediaCtrl c=IN IP4 as.example.com t=0 0 m=application 5757 TCP cfw a=connection:new a=setup:active a=cfw-id:5feb6486792a
2. AS <- MS (SIP 100 Trying)
----------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 203.0.113.1:5060; \
branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060
To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74
From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63
Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
CSeq: 1 INVITE
Content-Length: 0
3. AS <- MS (SIP 200 OK)
------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.0.113.1:5060; \
branch=z9hG4bK-d8754z-9b07c8201c3aa510-1---d8754z-;rport=5060
Contact: <sip:MediaServer@ms.example.net:5060>
To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74
From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63
Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
Content-Type: application/sdp
Content-Length: 199
v=0
o=lminiero 2890844526 2890842808 IN IP4 ms.example.net
s=MediaCtrl
c=IN IP4 ms.example.net
t=0 0
m=application 7575 TCP cfw
a=connection:new
a=setup:passive
a=cfw-id:5feb6486792a
4. AS -> MS (SIP ACK)
---------------------
ACK sip:MediaServer@ms.example.net:5060 SIP/2.0
Via: SIP/2.0/UDP 203.0.113.1:5060; \
branch=z9hG4bK-d8754z-22940f5f4589701b-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:ApplicationServer@203.0.113.1:5060>
To: <sip:MediaServer@ms.example.net:5060>;tag=499a5b74
From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63
Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
CSeq: 1 ACK
Content-Length: 0
5.2. SYNC
Once the AS and the MS have successfully established a TCP
connection, an additional step is needed before the Control Channel
can be used. In fact, as seen in the previous subsection, the first
interaction between the AS and the MS happens by means of a SIP
dialog, which in turn allows the creation of the TCP connection.
This introduces the need for a proper correlation between the above-
mentioned entities (SIP dialog and TCP connection), so that the MS
can be sure that the connection came from the AS that requested it.
This is accomplished by means of a dedicated framework message called
a SYNC message. This SYNC message uses a unique identifier called
the Dialog-ID to validate the Control Channel. This identifier, as
introduced previously, is meant to be globally unique and as such is
properly generated by the caller (the AS in the call flow) and added
as an SDP media attribute (cfw-id) to the COMEDIA negotiation in
order to make both entities aware of its value:
a=cfw-id:5feb6486792a
^^^^^^^^^^^^
It also offers an additional negotiation mechanism. In fact, the AS
uses the SYNC to not only properly correlate, as explained before,
but also negotiate with the MS the Control Packages in which it is
interested, as well as agree on a 'Keep-Alive' timer needed by both
the AS and the MS so that they will know if problems on the
connection occur. In the provided example (see Figure 6 and the
related call flow), the AS sends a SYNC with a Dialog-ID constructed
as needed (using the 'cfw-id' attribute from the SIP dialog) and
requests access to two Control Packages: specifically, the
Interactive Voice Response (IVR) package and the Mixer package. The
AS also instructs the MS that a 100-second timeout is to be used for
keep-alive messages. The MS validates the request by matching the
received Dialog-ID with the SIP dialog values, and, assuming that it
supports the Control Packages the AS requested access to (and for the
sake of this document we assume that it does), it answers with a
200 message. Additionally, the MS provides the AS with a list of other unrequested packages it supports (in this case just a dummy package providing testing functionality). AS MS . . . . | | | 1. SYNC (Dialog-ID, etc.) | |+++++++++++++++++++++++++++++>>| | |--+ | | | Check SYNC | |<-+ | 2. 200 OK | |<<+++++++++++++++++++++++++++++| | | . . . . Figure 6: SYNC: Sequence Diagram 1. AS -> MS (CFW SYNC) ---------------------- CFW 6e5e86f95609 SYNC Dialog-ID: 5feb6486792a Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0 2. AS <- MS (CFW 200) --------------------- CFW 6e5e86f95609 200 Keep-Alive: 100 Packages: msc-ivr/1.0,msc-mixer/1.0 Supported: msc-example-pkg/1.0 The framework-level transaction identifier is obviously the same in both the request and the response (6e5e86f95609), since the AS needs to be able to match the response to the original request. At this point, the Control Channel is finally established, and it can be used by the AS to request services from the MS.5.3. K-ALIVE
[RFC6230] provides a mechanism for implementing a keep-alive functionality. Such a mechanism is especially useful whenever any NAT or firewall sits in the path between an AS and an MS. In fact, NATs and firewalls may have timeout values for the TCP connections
they handle, which means that if no traffic is detected on these connections within a specific time they could be shut down. This could be the case for a Control Channel established between an AS and an MS but not used for some time. For this reason, [RFC6230] specifies a dedicated framework message (K-ALIVE) that the AS and MS can use in order to generate traffic on the TCP connection and keep it alive. As discussed in Section 5.2, the timeout value for the keep-alive mechanism is set by the SYNC request. Specifically, in the example, the AS specified a value of 100 seconds. In fact, the timeout value is not actually negotiated between the AS and MS, as it is simply specified by whichever endpoint takes the active role. The 100-second value is compliant with how NATs and firewalls are usually implemented, since in most cases the timeout value they use before shutting TCP connections down is around 2 minutes. Such a value has a strong meaning within the context of this mechanism. In fact, it means that the active role (the AS, in this case) has to send a K-ALIVE message before those 100 seconds pass; otherwise, the passive role (the MS) will tear down the connection, treating it like a timeout. [RFC6230] suggests a more conservative approach towards handling this timeout value, suggesting that the K-ALIVE message be triggered before 80% of the negotiated time passes (80 seconds, in this case). This is exactly the case presented in Figure 7. AS MS . . . . | | ~80 s have +--| | passed since | | | last K-ALIVE +->| | | 1. K-ALIVE | |+++++++++++++++++++++++++++++>>| | |--+ Reset the local | | | 'Keep-Alive' | |<-+ timer | 2. 200 OK | |<<+++++++++++++++++++++++++++++| Reset the +--| | local | | | 'Keep-Alive' +->| | timer | | . . . . Figure 7: K-ALIVE: Sequence Diagram
After the Control Channel has been established (COMEDIA+SYNC), both
the AS and the MS start local 'Keep-Alive' timers mapped to the
negotiated keep-alive timeout value (100 seconds). When about
80 seconds have passed since the start of the timer (80% of
100 seconds), the AS sends a framework-level K-ALIVE message to the
MS. The message as seen in the protocol message dump is very
lightweight, since it only includes a single line with no additional
header. When the MS receives the K-ALIVE message, it resets its
local 'Keep-Alive' timer and sends a 200 message back as
confirmation. As soon as the AS receives the 200 message, it resets
its local 'Keep-Alive' timer as well, and the mechanism starts over
again.
The actual transaction steps are presented below.
1. AS -> MS (K-ALIVE)
---------------------
CFW 518ba6047880 K-ALIVE
2. AS <- MS (CFW 200)
---------------------
CFW 518ba6047880 200
If the timer expired in either the AS or the MS (i.e., the K-ALIVE or
the 200 arrived after the 100 seconds), the connection and the
associated SIP control dialog would be torn down by the entity
detecting the timeout, thus ending the interaction between the AS and
the MS.
5.4. Wrong Behavior
This section will briefly address some types of behavior that could
represent the most common mistakes when dealing with the
establishment of a Control Channel between an AS and an MS. These
scenarios are obviously of interest, since they result in the AS and
the MS being unable to interact with each other. Specifically, these
simple scenarios will be described:
1. an AS providing the MS with a wrong Dialog-ID in the initial
SYNC.
2. an AS sending a generic CONTROL message instead of SYNC as a
first transaction.
The first scenario is depicted in Figure 8. AS MS . . . . | | | 1. SYNC (Dialog-ID, etc.) | |+++++++++++++++++++++++++++++>>| | |--+ | | | Check SYNC (wrong!) | |<-+ | 2. 481 | |<<+++++++++++++++++++++++++++++| | | |<-XX- CLOSE TCP CONNECTION -XX-| | | | SIP BYE | |------------------------------>| | | . . . . Figure 8: SYNC with Wrong Dialog-ID: Sequence Diagram This scenario is similar to the scenario presented in Section 5.2, but with a difference: instead of using the correct, expected Dialog-ID in the SYNC message (5feb6486792a, the one negotiated via COMEDIA), the AS uses a wrong value (4hrn7490012c). This causes the SYNC transaction to fail. First of all, the MS sends a framework- level 481 message. This response, when given in reply to a SYNC message, means that the SIP dialog associated with the provided Dialog-ID (the wrong identifier) does not exist. The Control Channel must be torn down as a consequence, and so the MS also closes the TCP connection it received the SYNC message from. The AS at this point is supposed to tear down its SIP control dialog as well, and so it sends a SIP BYE to the MS.
The actual transaction is presented below.
1. AS -> MS (CFW SYNC with wrong Dialog-ID)
-------------------------------------------
CFW 2b4dd8724f27 SYNC
Dialog-ID: 4hrn7490012c
Keep-Alive: 100
Packages: msc-ivr/1.0,msc-mixer/1.0
2. AS <- MS (CFW 481)
---------------------
CFW 2b4dd8724f27 481
The second scenario is depicted in Figure 9.
AS MS
. .
. .
| |
| 1. CONTROL |
|+++++++++++++++++++++++++++++>>|
| |--+ First transaction
| | | is not a SYNC
| |<-+
| 2. 403 |
|<<+++++++++++++++++++++++++++++|
| |
|<-XX- CLOSE TCP CONNECTION -XX-|
| |
| SIP BYE |
|------------------------------>|
| |
. .
. .
Figure 9: Incorrect First Transaction: Sequence Diagram
This scenario demonstrates another common mistake that could occur
when trying to set up a Control Channel. In fact, [RFC6230] mandates
that the first transaction after the COMEDIA negotiation be a SYNC to
conclude the setup. If the AS, instead of triggering a SYNC message
as expected, sends a different message to the MS (in the example
below, it tries to send an <audit> message addressed to the IVR
Control Package), the MS treats it like an error. As a consequence,
the MS replies with a framework-level 403 message (Forbidden) and,
just as before, closes the TCP connection and waits for the related
SIP control dialog to be torn down.
The actual transaction is presented below.
1. AS -> MS (CFW CONTROL instead of SYNC)
-----------------------------------------
CFW 101fbbd62c35 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 78
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<audit/>
</mscivr>
2. AS <- MS (CFW 403 Forbidden)
-------------------------------
CFW 101fbbd62c35 403
(page 20 continued on part 2)