tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7058

Informational
Pages: 182
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: MEDIACTRL

Media Control Channel Framework (CFW) Call Flow Examples

Part 1 of 6, p. 1 to 20
None       Next RFC Part

 


Top       ToC       Page 1 
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 Examples

Abstract

   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.

Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
   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).

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   +------------------+  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

Top      ToC       Page 9 
                 +--------------+   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

Top      ToC       Page 10 
                                    +--------------+
                                +-->| 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 Notifications

5.  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.

Top      ToC       Page 11 
               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 Establishment

5.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].

Top      ToC       Page 12 
                     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

Top      ToC       Page 13 
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

Top      ToC       Page 14 
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

Top      ToC       Page 15 
   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

Top      ToC       Page 16 
   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

Top      ToC       Page 17 
   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.

Top      ToC       Page 18 
   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.

Top      ToC       Page 19 
   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.

Top      ToC       Page 20 
   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)

Next RFC Part