Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7058

Media Control Channel Framework (CFW) Call Flow Examples

Pages: 182
Informational
Part 6 of 6 – Pages 157 to 182
First   Prev   None

Top   ToC   RFC7058 - Page 157   prevText

7.3. Handling Media Dialogs

It is worthwhile to briefly address how media dialogs would be managed whenever an MRB is involved in the following scenarios. In fact, the presence of an MRB may introduce an additional complexity compared to the quite straightforward 1:1 AS-MS topology.

7.3.1. Query and Inline-Aware Mode

Normally, especially in the Query and IAMM case, the MRB would only handle Consumer requests by an AS, and after that the AS and the MS picked by the MRB for a specific request would talk directly to each other by means of SIP. This is made possible by the fact that the AS gets the MS SIP URI in reply to its request. In this case, an AS can simply relay media dialogs associated with that session to the right MS to have them handled accordingly. Of course, in order for this to work it is assumed that the AS creates a Control Channel to a chosen MS before it has any requests to service. An example of such a scenario is presented in Figure 52. Please note that this diagram and subsequent diagrams in this section are simplified with respect to the actual protocol interactions. For
Top   ToC   RFC7058 - Page 158
   instance, the whole SIP transactions are not presented, and only the
   originating messages are presented in order to clarify the scenario
   in a simple way.

UAC              AS                           MRB                     MS
 |                |                            |                      |
 |                | 1. Consumer request        |                      |
 |                |--------------------------->|                      |
 |                |                            |                      |
 |                |       2. Consumer response |                      |
 |                |<---------------------------|                      |
 |                |                            |                      |
 |                | 3. COMEDIA negotiation to create CFW channel      |
 |                |-------------------------------------------------->|
 |                |                            |                      |
 |                |<<############## CFW CONNECTION #################>>|
 | 4. INVITE xyz  |                            |                      |
 |--------------->|                            |                      |
 |                | 5. Attach UAC to MS (3PCC)                        |
 |                |-------------------------------------------------->|
 |                |                            |                      |
 |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
 |                |                            |                      |
 .                .                            .                      .
 .                .                            .                      .

              Figure 52: Handling Media Dialogs in Query/IAMM

   As can be deduced from the diagram, the interactions among the
   components are quite straightforward.  The AS knows which MS it has
   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
   easily attach any UAC accessing its functionality to the MS itself
   and manipulate its media connections by using the CFW Control Channel
   as usual.

   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
   interfere with subsequent interactions unless it wants to perform
   monitoring (e.g., by exploiting the Publishing information reported
   by the MS).  As a consequence, the scenario basically becomes 1:1
   between the AS and the MS again.

   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
   the use of the resources.  Considering how the Consumer interface has
   been envisaged, this feature is easily achievable, with no change to
   the protocol required at all.  Specifically, in order to achieve such
Top   ToC   RFC7058 - Page 159
   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
   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
   interact with the MRB as if it were the MS itself.

   Figure 53 shows how the scenario would change in this case.

 UAC              AS                           MRB                    MS
  |                |                            |                      |
  |                | 1. Consumer request        |                      |
  |                |--------------------------->|                      |
  |                |                            |                      |
  |                |       2. Consumer response |                      |
  |                |<---------------------------|                      |
  |                |                            |                      |
  |                | 3. COMEDIA negotiation     |                      |
  |                |--------------------------->|                      |
  |                |                            | 4. COMEDIA neg.      |
  |                |                            |--------------------->|
  |                |                            |                      |
  |                |<<############## CFW CONNECTION #################>>|
  | 5. INVITE xyz  |                            |                      |
  |--------------->|                            |                      |
  |                | 6. Attach UAC to MS (3PCC) |                      |
  |                |--------------------------->|                      |
  |                |                            | 7. Attach UAC (3PCC) |
  |                |                            |--------------------->|
  |                |                            |                      |
  |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
  |                |                            |                      |
  .                .                            .                      .
  .                .                            .                      .

             Figure 53: Handling Media Dialogs in Query/IAMM:
                         MRB in the Signaling Path

   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
   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 actual MS transparently.  Eventually, the Control Channel would
   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
   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
   the UAC and the MS.
Top   ToC   RFC7058 - Page 160
   This scenario is not very different from the previous scenario,
   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 of the resources (e.g., triggering a BYE if a resource has
   expired).  There are several possible approaches an MRB might take to
   allocate URIs to map to a requested MS.  For example, an MRB might
   use SIP URI parameters to generate multiple SIP URIs that are unique
   but that all route to the same host and port, e.g.,
   sip:MrbToMs@mrb.example.com:5080;p=1234567890.  Alternatively, the
   MRB might simply allocate a pool of URIs for which it would be
   responsible and manage the associations with the requested MS
   services accordingly.

7.3.2. Inline-Unaware Mode

As mentioned previously, in the IUMM case the AS would interact with the MRB as if it were the MS itself. One might argue that this would make the AS act as it would in the IAMM case. This is not the case, however, since the AS actually provided the MRB with information about the resources it required, leading to the selection of a proper MS, while in the IUMM case the MRB would have to pick an MS with no help from the AS at all. That said, the IUMM case is also very interesting with respect to 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 an MS. Unlike the previous scenarios, because there is no AS<->MRB 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. The MRB could either redirect the AS to an MS directly or transparently act as a Proxy/B2BUA and contact an MS (according to implementation-specific policies) on behalf of the unaware AS. While apparently not a problem, this raises an issue when the same 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 there, making it hard for the MRB to understand where these media dialogs should belong: specifically, whether the UAC calling belongs to the AS application logic leading to MS1 or MS2, or somewhere else.
Top   ToC   RFC7058 - Page 161
   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
   MS, as depicted in Figure 54.

UAC1  UAC2       AS                           MRB                     MS
 |     |          |                            |                      |
 |     |          | 1. COMEDIA negotiation (A) |                      |
 |     |          |--------------------------->|                      |
 |     |          |                            | 2. COMEDIA neg. (A)  |
 |     |          |                            |--------------------->|
 |     |          |                            |                      |
 |     |          |<<############## CFW CONNECTION #################>>|
 |     |          |                            |                      |
 |     |          | 3. COMEDIA negotiation (B) |                      |
 |     |          |--------------------------->|                      |
 |     |          |                            | 4. COMEDIA neg. (B)  |
 |     |          |                            |--------------------->|
 |     |          |                            |                      |
 |     |          |<<############## CFW CONNECTION #################>>|
 | 5. INVITE xyz  |                            |                      |
 |--------------->|                            |                      |
 |     |          | 6. Attach UAC1 to MS (3PCC)|                      |
 |     |          |--------------------------->|                      |
 |     |          |                            | 7. Attach UAC (3PCC) |
 |     |          |                            |--------------------->|
 |     |          |                            |                      |
 |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
 |     |          |                            |                      |
 |     | 8. INVITE|                            |                      |
 |     |    jkl   |                            |                      |
 |     |--------->|                            |                      |
 |     |          | 9. Attach UAC2 to MS (3PCC)|                      |
 |     |          |--------------------------->|                      |
 |     |          |                            | 10. Attach UAC (3PCC)|
 |     |          |                            |--------------------->|
 |     |          |                            |                      |
 |     |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
 |     |          |                            |                      |
 .     .          .                            .                      .
 .     .          .                            .                      .

       Figure 54: Handling Media Dialogs in IUMM: Always the Same MS

   In this example, the AS creates two different Control Channel
   sessions (A and B) to address two different business logic
   implementations; e.g., the AS SIP URI 'xyz' (associated with CFW
   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
Top   ToC   RFC7058 - Page 162
   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
   dialogs would prove troublesome, because the MRB would have
   difficulty figuring out whether UAC1 should be attached to the MS
   managing CFW session A or the MS managing CFW session B.  In this
   example, forwarding all CFW sessions and UAC media dialogs coming
   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
   sessions up to the AS.

   This approach, while very simple and indeed not very scalable, would
   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
   example, Control Channel A would be mapped to application xyz and
   Control Channel B to application jkl), the termination point would
   still always be the same MS, which would consequently be the
   destination for all media dialogs as well.

   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
   different approach needs to be exploited.  In fact, especially in the
   case of different applications handled by the same unaware AS, it
   makes sense to try to exploit different MS for that purpose and to
   correctly track media dialogs being forwarded accordingly.  This
   means that the MRB must find a way to somehow redirect the unaware AS
   to different MS when it predicts or realizes that a different
   application logic is involved.
Top   ToC   RFC7058 - Page 163
   To do so, the MRB might use different approaches.  One approach would
   use redirection, e.g., by means of a SIP 302 message in reply to a
   Control Channel negotiation originated by an unaware AS.  Such an
   approach is depicted in Figure 55.

UAC1             AS                           MRB                     MS
 |                |                            |                      |
 |                | 1. COMEDIA negotiation     |                      |
 |                |--------------------------->|                      |
 |                |                            |                      |
 |                |          2. 302 Moved (MS) |                      |
 |                |<---------------------------|                      |
 |                |                            |                      |
 |                | 3. COMEDIA negotiation     |                      |
 |                |-------------------------------------------------->|
 |                |                            |                      |
 |                |<<############## CFW CONNECTION #################>>|
 |                |                            |                      |
 | 4. INVITE xyz  |                            |                      |
 |--------------->|                            |                      |
 |                | 5. Attach UAC1 to MS (3PCC)|                      |
 |                |-------------------------------------------------->|
 |                |                            |                      |
 |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
 |                |                            |                      |
 .                .                            .                      .
 .                .                            .                      .

          Figure 55: Handling Media Dialogs in IUMM: Redirection

   With this approach, the MRB might redirect the AS to a specific MS
   whenever a new Control Channel is to be created, and as a consequence
   the AS would redirect the related calls there.  This is similar to
   the first approach of the Query/IAMM case, with the difference that
   no Consumer request would be involved.  The scenario would again fall
   back to a 1:1 topology between the AS and the MS, making the
   interactions quite simple.

   Just as before, the MRB might be interested in being in the signaling
   path for the SIP dialogs, instead of just acting as a locator.  A
   third potential approach could be implementing the "virtual" URIs
   handled by the MRB, as described in the previous section.  Rather
   than resorting to explicit redirection or always using the same MS,
Top   ToC   RFC7058 - Page 164
   the MRB may redirect new SIP control dialogs to one of its own URIs,
   using the same approach previously presented in Figure 53.  Such an
   approach, as applied to the IUMM case, is depicted in Figure 56.

UAC1             AS                              MRB                  MS
 |                |                               |                   |
 |                | 1. COMEDIA negotiation (MRB)  |                   |
 |                |------------------------------>|                   |
 |                |                               |                   |
 |                |           2. 302 Moved (MRB') |                   |
 |                |<------------------------------|                   |
 |                |                               |                   |
 |                | 3. COMEDIA negotiation (MRB') |                   |
 |                |------------------------------>|                   |
 |                |                               | 4. COMEDIA neg.   |
 |                |                               |------------------>
 |                |                               |                   |
 |                |<<############## CFW CONNECTION #################>>|
 |                |                               |                   |
 | 5. INVITE xyz  |                               |                   |
 |--------------->|                               |                   |
 |                | 6. Attach UAC1 to MRB' (3PCC) |                   |
 |                |------------------------------>|                   |
 |                |                               | 7 Attach UAC (3PCC)
 |                |                               |------------------>
 |                |                               |                   |
 |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>|
 |                |                               |                   |
 .                .                               .                   .
 .                .                               .                   .

   Figure 56: Handling Media Dialogs in IUMM: MRB in the Signaling Path

   It is worth pointing out, though, that in both cases there are
   scenarios where there could be no assurance that the 302 sent by the
   MRB would be seen by the AS.  In fact, should a proxy be between the
   AS and the MRB, such a proxy could itself act on the 302.  To
   properly cope with such an issue, the MRB might also use the
   'Contact' header in the SIP responses to the INVITE to address the
   right MS.  Although the AS is not required to use the information in
   such a header to reach the MS, it could be reasonable to exploit it
   for that purpose, as it would take care of the proxy scenario
   mentioned above.
Top   ToC   RFC7058 - Page 165
   To conclude, there is a further approach an MRB might try to exploit
   to take care of the IUMM case.  Since, as explained before, the
   issues related to the IUMM case mostly relate to the fact that the
   MRB is seen as a single MS instance by the AS, a simple way to
   overcome this might be to make the MRB look like a set of different
   MS right away; this can be done by simply provisioning the unaware AS
   with a series of different URIs, all handled by the MRB itself acting
   as a pool of "virtual" MS.  This way, the AS may be designed to use
   different MS for different classes of calls, e.g., for different
   applications it is managing (two in the example presented in this
   section), and as such would contact two different provisioned URIs to
   create two distinct Control Channels towards two different MS.  Since
   both of the URIs would be handled by the MRB, the MRB can use them to
   determine to which MS each call should be directed.  Expanding on
   Figure 54 by removing the constraint to always use the same MS, this
   new scenario might look like that depicted in Figure 57.
Top   ToC   RFC7058 - Page 166
 UAC1  UAC2       AS                           MRB              MS1  MS2
  |     |          |                            |                 |    |
  |     |          | 1. COMEDIA negotiation (A) |                 |    |
  |     |          |    INVITE fake-ms1         |                 |    |
  |     |          |--------------------------->|                 |    |
  |     |          |                            | 2. COMEDIA (A)  |    |
  |     |          |                            |---------------->|    |
  |     |          |                            |                 |    |
  |     |          |<<############## CFW CONNECTION 1 ##########>>|    |
  |     |          |                            |                 |    |
  |     |          | 3. COMEDIA negotiation (B) |                 |    |
  |     |          |    INVITE fake-ms2         |                 |    |
  |     |          |--------------------------->|                 |    |
  |     |          |                            | 4. COMEDIA neg. (B)  |
  |     |          |                            |--------------------->|
  |     |          |                            |                 |    |
  |     |          |<<############## CFW CONNECTION 2 ###############>>|
  |     |          |                            |                 |    |
  | 5. INVITE xyz  |                            |                 |    |
  |--------------->|                            |                 |    |
  |     |          | 6. Attach UAC1 to fake-ms1 (3PCC)            |    |
  |     |          |--------------------------->|                 |    |
  |     |          |                            | 7. Attach UAC   |    |
  |     |          |                            |---------------->|    |
  |     |          |                            |                 |    |
  |<<++++++++++++++++++++++ RTP channels +++++++++++++++++++++++>>|    |
  |     |          |                            |                 |    |
  | 8. INVITE jkl  |                            |                 |    |
  |--------------->|                            |                 |    |
  |     |          | 9. Attach UAC2 to fake-ms2 (3PCC)            |    |
  |     |          |--------------------------->|                 |    |
  |     |          |                            | 10. Attach UAC  |    |
  |     |          |                            |--------------------->|
  |     |          |                            |                 |    |
  |<<+++++++++++++++++++++++++ RTP channels +++++++++++++++++++++++++>>|
  |     |          |                            |                 |    |
  .     .          .                            .                 .    .
  .     .          .                            .                 .    .

        Figure 57: Handling Media Dialogs in IUMM: Provisioned URIs

   In this new example, we still assume that the same unaware AS is
   handling two different applications, still associated with the same
   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
   very different applications for which it is responsible.  We also
   assume that it has been configured to be able to use two different MS
   instances, reachable at SIP URI 'fake-ms1' and 'fake-ms2',
Top   ToC   RFC7058 - Page 167
   respectively, and both actually handled by the MRB transparently.
   This results, just as before, in two different Control Channels (A
   and B) being created, but this time towards two different MS.
   Specifically, the MRB makes sure that for this AS the Control Channel
   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
   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.
   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
   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
   room.  This time, the AS attaches this new media dialog to the MS
   instance handling the conference application, i.e., 'fake-ms2'.
   Again, the MRB makes sure that it is actually MS2 that receives the
   dialog.

   Again, this diagram is only meant to describe how the MRB might
   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 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
   a SIP redirect, as explained before) and let the AS attach the media
   dialogs by itself.

7.3.3. CFW Protocol Behavior

As shown in the previous diagrams, no matter what the topology, the AS and MS usually end up with a direct connection with respect to the CFW Control Channel. As such, it can be expected that the CFW protocol continue to work as it should, and as a consequence all the call flows presented in this document can easily be reproduced in those circumstances as well. Nevertheless, one aspect needs to be considered very carefully. It's worthwhile to remind readers that both the AS and the MS use some SIP-related information to address the entities they manipulate. This is the case, for instance, for the <connectionid> element to which both the AS and the MS refer when addressing a specific UAC. As explained in Section 6, this 'connectionid' identifier is constructed by concatenating the 'From' and 'To' tags extracted from a SIP header: specifically, from the headers of the AS<->MS leg that allows a UAC to be attached to the MS. The presence of an additional component in the path between the AS and the MS, the MRB, might alter these tags, thus causing the AS to use tags (AS<->MRB) different than those used by the MS (MRB<->MS). This would result in the AS and MS using different 'connectionid' identifiers to address the same UAC, thus preventing the protocol from working as expected. As a
Top   ToC   RFC7058 - Page 168
   consequence, it's very important that any MRB implementation take
   very good care to preserve the integrity of the involved SIP headers
   when proxying/forwarding SIP dialogs between the AS and MS, in order
   not to "break" the behavior of the protocol.

   Let's take, for instance, the scenario depicted in Figure 53,
   especially steps 6 and 7, which specifically address a UAC being
   attached by an AS to an MS via the MRB.  Let's assume that Figure 58
   shows what happens to the 'From' and 'To' headers in that scenario,
   when dealing with the 3PCC approach to attach a specific UAC to
   the MS.

UAC              AS                         MRB                       MS
 |                |                          |                        |
 | INVITE xyz     |                          |                        |
 |--------------->|                          |                        |
 |                | SIP [..]                 |                        |
 |                | From: <..>;tag=a1b2c3    |                        |
 |                | To: <..>;tag=d4e5f6      |                        |
 |                |<------------------------>|                        |
 |                |                          | SIP [..]               |
 |                |                          | From: <..>;tag=aaabbb  |
 |                |                          | To: <..>;tag=cccddd    |
 |                |                          |<---------------------->|
 |                |                          |                        |
 |                | 1. CONTROL (play announcement to UAC)             |
 |                |-------------------------------------------------->|
 |                |                               2. 200 (IVR Error!) |
 |                |<--------------------------------------------------|
 |                |                          |                        |
 .                .                          .                        .
 .                .                          .                        .

     Figure 58: CFW Protocol Behavior in the Case of Manipulated Tags

   In this example, once done with the 3PCC, and now that the UAC is
   attached to the MS, the AS and the MS end up with different
   interpretations of what the 'connectionid' for the UAC should be.  In
   fact, the AS builds a 'connectionid' using the tags it is aware of
   (a1b2c3:d4e5f6), while the MS builds a different identifier after
   receiving different information from the MRB (aaabbb:cccddd).

   As a consequence, when the AS tries to play an announcement to the
   UAC using the connectionid it correctly constructed, the MS just as
   correctly replies with an error, since it doesn't know that
   identifier.  This is correct protocol behavior, because in this case
   it was caused by misuse of the information needed for it to work as
   expected.
Top   ToC   RFC7058 - Page 169
   1. AS -> MS (CFW CONTROL, play)
   -------------------------------
      CFW ffhg45dzf123 CONTROL
      Control-Package: msc-ivr/1.0
      Content-Type: application/msc-ivr+xml
      Content-Length: 284

      <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
        <dialogstart connectionid="a1b2c3:d4e5f6">
          <dialog>
            <prompt>
              <media loc="http://www.example.net/hello.wav"/>
            </prompt>
          </dialog>
        </dialogstart>
      </mscivr>


   2. AS <- MS (CFW 200 OK)
   ------------------------
      CFW ffhg45dzf123 200
      Timeout: 10
      Content-Type: application/msc-ivr+xml
      Content-Length: 148

      <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
        <response status="407" reason="connectionid does not exist"
                  dialogid=""/>
      </mscivr>

   In an even worse scenario, the connectionid might actually exist but
   might be mapped to a different UAC.  In such a case, the transaction
   would succeed, but a completely different UAC would be involved, thus
   causing a silent failure that neither the AS nor the MS would be
   aware of.

   That said, proper management of these sensitive pieces of information
   by the MRB would prevent such failure scenarios from happening.  How
   this issue is taken care of in the IAMM case (both CFW-based and
   media dialog-based) has already been described.  Addressing this
   issue for the IUMM case is not documented in [RFC6917] as explicitly
   out of scope and as such may be implementation specific.

   The same applies to SDP fields as well.  In fact, the AS and MS use
   ad hoc SDP attributes to instantiate a Control Channel, as they use
   SDP labels to address specific media connections of a UAC media
   dialog when a fine-grained approach is needed.  As a consequence, any
Top   ToC   RFC7058 - Page 170
   MRB implementation should limit any SDP manipulation as much as
   possible or at least take very good care not to cause changes that
   could "break" the expected behavior of the CFW protocol.

8. Security Considerations

All the MEDIACTRL documents have strong statements regarding security considerations within the context of the interactions occurring at all levels among the involved parties. Considering the sensitive nature of the interaction between AS and MS, particular efforts have been devoted to providing guidance on how to secure what flows through a Control Channel. In fact, transactions concerning dialogs, connections, and mixes are quite strongly related to resources actually being deployed and used in the MS. This means that it is in the interest of both AS and MS that resources created and handled by an entity are not manipulated by a potentially malicious third party if permission was not granted. Because strong statements are provided in the aforementioned documents and these documents provide good guidance to implementors with respect to these issues, this section will only provide the reader with some MEDIACTRL call flows that show how a single secured MS is assumed to reply to different AS when receiving requests that may cross the bounds within which each AS is constrained. This would be the case, for instance, for generic auditing requests, or explicit conference manipulation requests where the involved identifiers are not part of the context of the originating AS. To address a very specific scenario, let's assume that two different AS, AS1 and AS2, have established a Control Channel with the same MS. Considering the SYNC transaction that an AS and an MS use to set up a Control Channel, the MS is able to discern the requests coming from AS1 from the requests coming from AS2. In fact, as explained 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 on the Control Channel that is created after the negotiation, thus reassuring both the AS and the MS that the Control Channel they share is in fact the channel they negotiated in the first place.
Top   ToC   RFC7058 - Page 171
   Let's also assume that AS1 has created a conference mix
   (confid=74b6d62) to which it has attached some participants within
   the context of its business logic, while AS2 has created a currently
   active IVR dialog (dialogid=dfg3252) with a user agent it is handling
   (237430727:a338e95f).  AS2 has also joined two connections to each
   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
   versa, and that they not be allowed to manipulate each other's
   resources.  The following transactions will occur:

   1.  AS1 places a generic audit request to both the Mixer and IVR
       packages.

   2.  AS2 places a generic audit request to both the Mixer and IVR
       packages.

   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
       conference mix created by AS1 (74b6d62).
Top   ToC   RFC7058 - Page 172
   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,
   in order to avoid security issues:

      AS1                     AS2                                 MS
       |                       |                                  |
       | A1. CONTROL (IVR audit)                                  |
       |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
       |                       |                       A2. 200 OK |
       |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
       |                       |                                  |
       | B1. CONTROL (Mixer audit)                                |
       |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
       |                       |                       B2. 200 OK |
       |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
       |                       |                                  |
       |                       | C1. CONTROL (IVR audit)          |
       |                       |++++++++++++++++++++++++++++++++>>|
       |                       |                       C2. 200 OK |
       |                       |<<++++++++++++++++++++++++++++++++|
       |                       |                                  |
       |                       | D1. CONTROL (Mixer audit)        |
       |                       |++++++++++++++++++++++++++++++++>>|
       |                       |                       D2. 200 OK |
       |                       |<<++++++++++++++++++++++++++++++++|
       |                       |                                  |
       | E1. CONTROL (dialogterminate)                            |
       |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>|
       |                       |                E2. 403 Forbidden |
       |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
       |                       |                                  |
       |                       | F1. CONTROL (join UAC&conf[AS1]) |
       |                       |++++++++++++++++++++++++++++++++>>|
       |                       |                F2. 403 Forbidden |
       |                       |<<++++++++++++++++++++++++++++++++|
       |                       |                                  |
       .                       .                                  .
       .                       .                                  .

         Figure 59: Security Considerations: Framework Transaction
Top   ToC   RFC7058 - Page 173
   The expected outcome of the transaction is that the MS partially
   "lies" to both AS1 and AS2 when replying to the audit requests (not
   all of the identifiers are reported, but only those identifiers with
   which each AS is directly involved), and the MS denies the requests
   for the unauthorized operations (403).  Looking at each transaction
   separately:

   o  In the first transaction (A1), AS1 places a generic <audit>
      request to the IVR package.  The request is generic, since no
      attributes are passed as part of the request, meaning that AS1 is
      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
      (A2), the MS only reports in the <auditresponse> the package
      capabilities, while the <dialogs> element is empty; this is
      because the only dialog the MS is handling has actually been
      created by AS2, which causes the MS not to report the related
      identifier (6791fee) to AS1.  In fact, AS1 could use that
      identifier to manipulate the dialog, e.g., by tearing it down and
      thus causing the service to be interrupted without AS2's
      intervention.

   o  In the second transaction (B1), AS1 places an identical <audit>
      request to the Mixer package.  The request is again generic,
      meaning that AS1 is interested in the package capabilities as well
      as all the mixers and connections that the package is handling at
      the moment.  This time, the MS reports not only capabilities (B2)
      but information about mixers and connections as well.  However,
      this information is not complete; in fact, only information about
      mixers and connections originated by AS1 is reported (mixer
      74b6d62 and its participants), while the information originated by
      AS2 is 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
      places an <audit> request to both the IVR and Mixer packages.  As
      with the previous transactions, the audit requests are generic.
      Looking at the replies (C2 and D2), it's obvious that the
      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
      <dialogs> and <mixers> sections are totally different.  AS2 in
      fact receives information about its own IVR dialog (6791fee),
      which was omitted in the reply to AS1, while it only receives
      information about the only connection it created (1:75d4dd0d and
      1:b9e6a659) without any details related to the mixers and
      connections originated by AS1.
Top   ToC   RFC7058 - Page 174
   o  In the fifth transaction (E1), AS1, instead of just auditing the
      packages, tries to terminate (<dialogterminate>) the dialog
      created by AS2 (6791fee).  Since the identifier has not been
      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.
      This is assumed to be an unauthorized operation, because the
      above-mentioned dialog is outside the bounds of AS1; therefore,
      the MS, instead of handling the syntactically correct request,
      replies (E2) with a framework-level 403 message (Forbidden),
      leaving the dialog untouched.

   o  Similarly, in the sixth and last transaction (F1), AS2 tries to
      attach (<join>) one of the UACs it is handling to the conference
      mix created by AS1 (74b6d62).  Just as in the previous
      transaction, the identifier is assumed to have been accessed by
      AS2 via some out-of-band mechanism, since the MS didn't report it
      in the reply to the previous audit request.  While one of the
      identifiers (the UAC) is actually handled by AS2, the other (the
      conference mix) is not; therefore, as with the fifth transaction,
      this last transaction is regarded by the MS as outside the bounds
      of AS2.  For the same reason as before, the MS replies (F2) with a
      framework-level 403 message (Forbidden), leaving the mix and the
      UAC unjoined.

  A1. AS1 -> MS (CFW CONTROL, audit IVR)
  --------------------------------------
     CFW 140e0f763352 CONTROL
     Control-Package: msc-ivr/1.0
     Content-Type: application/msc-ivr+xml
     Content-Length: 81

     <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
        <audit/>
     </mscivr>
Top   ToC   RFC7058 - Page 175
  A2. AS1 <- MS (CFW 200, auditresponse)
  --------------------------------------
     CFW 140e0f763352 200
     Timeout: 10
     Content-Type: application/msc-ivr+xml
     Content-Length: 1419

     <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <auditresponse status="200">
        <capabilities>
           <dialoglanguages/>
           <grammartypes/>
           <recordtypes>
              <mimetype>audio/x-wav</mimetype>
              <mimetype>video/mpeg</mimetype>
           </recordtypes>
           <prompttypes>
              <mimetype>audio/x-wav</mimetype>
              <mimetype>video/mpeg</mimetype>
           </prompttypes>
           <variables>
              <variabletype type="date"
                            desc="value formatted as YYYY-MM-DD">
                 <format desc="month day year">mdy</format>
                 <format desc="year month day">ymd</format>
                 <format desc="day month year">dmy</format>
                 <format desc="day month">dm</format>
              </variabletype>
              <variabletype type="time" desc="value formatted as HH:MM">
                 <format desc="24 hour format">t24</format>
                 <format desc="12 hour format with am/pm">t12</format>
              </variabletype>
              <variabletype type="digits" desc="value formatted as D+">
                 <format desc="general digit string">gen</format>
                 <format desc="cardinal">crn</format>
                 <format desc="ordinal">ord</format>
              </variabletype>
           </variables>
           <maxpreparedduration>60s</maxpreparedduration>
           <maxrecordduration>1800s</maxrecordduration>
           <codecs>
              <codec name="audio"><subtype>basic</subtype></codec>
              <codec name="audio"><subtype>gsm</subtype></codec>
              <codec name="video"><subtype>h261</subtype></codec>
              <codec name="video"><subtype>h263</subtype></codec>
              <codec name="video"><subtype>h263-1998</subtype></codec>
              <codec name="video"><subtype>h264</subtype></codec>
           </codecs>
Top   ToC   RFC7058 - Page 176
        </capabilities>
        <dialogs>
        </dialogs>
     </auditresponse>
     </mscivr>


  B1. AS1 -> MS (CFW CONTROL, audit mixer)
  ----------------------------------------
     CFW 0216231b1f16 CONTROL
     Control-Package: msc-mixer/1.0
     Content-Type: application/msc-mixer+xml
     Content-Length: 87

     <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
        <audit/>
     </mscmixer>


  B2. AS1 <- MS (CFW 200, auditresponse)
  --------------------------------------
     CFW 0216231b1f16 200
     Timeout: 10
     Content-Type: application/msc-mixer+xml
     Content-Length: 903

     <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <auditresponse status="200">
       <capabilities>
          <codecs>
             <codec name="audio"><subtype>basic</subtype></codec>
             <codec name="audio"><subtype>gsm</subtype></codec>
             <codec name="video"><subtype>h261</subtype></codec>
             <codec name="video"><subtype>h263</subtype></codec>
             <codec name="video"><subtype>h263-1998</subtype></codec>
             <codec name="video"><subtype>h264</subtype></codec>
          </codecs>
       </capabilities>
       <mixers>
         <conferenceaudit conferenceid="74b6d62">
           <participants>
             <participant id="1864574426:e2192766"/>
             <participant id="1:5a97fd79"/>
           </participants>
           <video-layout min-participants="1">
             <quad-view/>
           </video-layout>
         </conferenceaudit>
Top   ToC   RFC7058 - Page 177
         <joinaudit id1="1864574426:e2192766" id2="74b6d62"/>
         <joinaudit id1="1:5a97fd79" id2="74b6d62"/>
       </mixers>
     </auditresponse>
     </mscmixer>


  C1. AS2 -> MS (CFW CONTROL, audit IVR)
  --------------------------------------
     CFW 0216231b1f16 CONTROL
     Control-Package: msc-ivr/1.0
     Content-Type: application/msc-ivr+xml
     Content-Length: 81

     <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
        <audit/>
     </mscivr>


  C2. AS2 <- MS (CFW 200, auditresponse)
  --------------------------------------
     CFW 0216231b1f16 200
     Timeout: 10
     Content-Type: application/msc-ivr+xml
     Content-Length: 1502

     <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
     <auditresponse status="200">
        <capabilities>
           <dialoglanguages/>
           <grammartypes/>
           <recordtypes>
              <mimetype>audio/wav</mimetype>
              <mimetype>video/mpeg</mimetype>
           </recordtypes>
           <prompttypes>
              <mimetype>audio/wav</mimetype>
              <mimetype>video/mpeg</mimetype>
           </prompttypes>
           <variables>
              <variabletype type="date"
                            desc="value formatted as YYYY-MM-DD">
                 <format desc="month day year">mdy</format>
                 <format desc="year month day">ymd</format>
                 <format desc="day month year">dmy</format>
                 <format desc="day month">dm</format>
              </variabletype>
Top   ToC   RFC7058 - Page 178
              <variabletype type="time" desc="value formatted as HH:MM">
                 <format desc="24 hour format">t24</format>
                 <format desc="12 hour format with am/pm">t12</format>
              </variabletype>
              <variabletype type="digits" desc="value formatted as D+">
                 <format desc="general digit string">gen</format>
                 <format desc="cardinal">crn</format>
                 <format desc="ordinal">ord</format>
              </variabletype>
           </variables>
           <maxpreparedduration>60s</maxpreparedduration>
           <maxrecordduration>1800s</maxrecordduration>
           <codecs>
              <codec name="audio"><subtype>basic</subtype></codec>
              <codec name="audio"><subtype>gsm</subtype></codec>
              <codec name="video"><subtype>h261</subtype></codec>
              <codec name="video"><subtype>h263</subtype></codec>
              <codec name="video"><subtype>h263-1998</subtype></codec>
              <codec name="video"><subtype>h264</subtype></codec>
           </codecs>
        </capabilities>
        <dialogs>
           <dialogaudit dialogid="6791fee" state="started"
                        connectionid="237430727:a338e95f"/>
        </dialogs>
     </auditresponse>
     </mscivr>


  D1. AS2 -> MS (CFW CONTROL, audit mixer)
  ----------------------------------------
     CFW 515f007c5bd0 CONTROL
     Control-Package: msc-mixer/1.0
     Content-Type: application/msc-mixer+xml
     Content-Length: 87

     <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
        <audit/>
     </mscmixer>
Top   ToC   RFC7058 - Page 179
  D2. AS2 <- MS (CFW 200, auditresponse)
  --------------------------------------
     CFW 515f007c5bd0 200
     Timeout: 10
     Content-Type: application/msc-mixer+xml
     Content-Length: 548

     <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <auditresponse status="200">
        <capabilities>
           <codecs>
              <codec name="audio"><subtype>basic</subtype></codec>
              <codec name="audio"><subtype>gsm</subtype></codec>
              <codec name="video"><subtype>h261</subtype></codec>
              <codec name="video"><subtype>h263</subtype></codec>
              <codec name="video"><subtype>h263-1998</subtype></codec>
              <codec name="video"><subtype>h264</subtype></codec>
           </codecs>
        </capabilities>
        <mixers>
           <joinaudit id1="1:75d4dd0d" id2="1:b9e6a659"/>
        </mixers>
     </auditresponse>
     </mscmixer>


  E1. AS1 -> MS (CFW CONTROL, dialogterminate)
  --------------------------------------------
     CFW 7fdcc2331bef CONTROL
     Control-Package: msc-ivr/1.0
     Content-Type: application/msc-ivr+xml
     Content-Length: 127

     <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
        <dialogterminate dialogid="6791fee" immediate="true"/>
     </mscivr>


  E2. AS1 <- MS (CFW 403 Forbidden)
  ---------------------------------
     CFW 7fdcc2331bef 403
Top   ToC   RFC7058 - Page 180
  F1. AS2 -> MS (CFW CONTROL, join to conference)
  -----------------------------------------------
     CFW 140e0f763352 CONTROL
     Control-Package: msc-mixer/1.0
     Content-Type: application/msc-mixer+xml
     Content-Length: 117

     <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
        <join id1="1:272e9c05" id2="74b6d62"/>
     </mscmixer>


  F2. AS2 <- MS (CFW 403 Forbidden)
  ---------------------------------
     CFW 140e0f763352 403

9. Acknowledgments

The authors would like to thank Dale Worley for the thorough review of the whole document and for contributing text to make the document easier to read.

10. References

10.1. Normative References

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
Top   ToC   RFC7058 - Page 181
   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572, July 2006.

   [RFC6230]  Boulton, C., Melanchuk, T., and S. McGlashan, "Media
              Control Channel Framework", RFC 6230, May 2011.

   [RFC6231]  McGlashan, S., Melanchuk, T., and C. Boulton, "An
              Interactive Voice Response (IVR) Control Package for the
              Media Control Channel Framework", RFC 6231, May 2011.

   [RFC6505]  McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
              Control Package for the Media Control Channel Framework",
              RFC 6505, March 2012.

   [RFC6917]  Boulton, C., Miniero, L., and G. Munson, "Media Resource
              Brokering", RFC 6917, April 2013.

   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
              Centralized Conferencing", RFC 5239, June 2008.

   [RFC4582]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
              Control Protocol (BFCP)", RFC 4582, November 2006.

   [RFC4583]  Camarillo, G., "Session Description Protocol (SDP) Format
              for Binary Floor Control Protocol (BFCP) Streams",
              RFC 4583, November 2006.

10.2. Informative References

[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar Specification Version 1.0", W3C Recommendation, March 2004. [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006. [RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.
Top   ToC   RFC7058 - Page 182

Authors' Addresses

Alessandro Amirante University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: alessandro.amirante@unina.it Tobia Castaldi Meetecho Via Carlo Poerio 89 Napoli 80100 Italy EMail: tcastaldi@meetecho.com Lorenzo Miniero Meetecho Via Carlo Poerio 89 Napoli 80100 Italy EMail: lorenzo@meetecho.com Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: spromano@unina.it