7.  Media Resource Brokering

   All the flows presented so far describe the interaction between a
   single AS and a single MS.  This is the simplest topology that can be
   envisaged in a MEDIACTRL-compliant architecture, but it's not the
   only topology that is allowed.  [RFC5567] presents several possible
   topologies that potentially involve several AS and several MS as
   well.  To properly allow for such topologies, an additional element
   called the Media Resource Broker (MRB) has been introduced in the
   MEDIACTRL architecture.  Such an entity, and the protocols needed to
   interact with it, has been standardized in [RFC6917].

   An MRB is basically a locator that is aware of a pool of MS and makes
   them available to interested AS according to their requirements.  For
   this reason, two different interfaces have been introduced:

   o  the Publishing interface (Section 7.1), which allows an MRB to
      subscribe for notifications at the MS it is handling (e.g.,
      available and occupied resources, current state, etc.).

   o  the Consumer interface (Section 7.2), which allows an interested
      AS to query an MRB for an MS capable of fulfilling its
      requirements.

   The flows in the following sections will present some typical
   use-case scenarios involving an MRB and the different topologies in
   which it has been conceived to work.

   Additionally, a few considerations on the handling of media dialogs
   whenever an MRB is involved are presented in Section 7.3.

7.1.  Publishing Interface

   An MRB uses the MS's Publishing interface to acquire relevant
   information.  This Publishing interface, as specified in [RFC6917],
   is made available as a Control Package for the Media Control Channel
   Framework.  This means that in order to receive information from an
   MS, an MRB must negotiate a Control Channel as explained in
   Section 5.  This package allows an MRB to either request information
   in the form of a direct request/answer from an MS or subscribe for
   events.

   Of course, since the MRB is interested in the Publishing interface,
   the previously mentioned negotiation must be changed in order to take
   into account the need for the MRB Control Package.  The name of this
   package is 'mrb-publish/1.0', which means that the SYNC might look
   like the following:

   1. MRB -> MS (CFW SYNC)
   -----------------------
      CFW 6b8b4567327b SYNC
      Dialog-ID: z9hG4bK-4542-1-0
      Keep-Alive: 100
      Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0

   2. MRB <- MS (CFW 200)
   ----------------------
      CFW 6b8b4567327b 200
      Keep-Alive: 100
      Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0
      Supported: msc-example-pkg/1.0

   The meaning of this negotiation was presented previously.  It is
   enough to point out that the MRB in this case adds a new item to the
   'Packages' it needs support for (mrb-publish/1.0).  In this case, the
   MS supports it, and in fact it is added to the negotiated packages in
   the reply:

           Packages: msc-ivr/1.0,msc-mixer/1.0,mrb-publish/1.0
                                               ^^^^^^^^^^^^^^^

   The MS as described in Section 5, on the other hand, did not have
   support for that package, since only 'msc-example-pkg/1.0' was part
   of the 'Supported' list.

   Figure 47 presents a ladder diagram of a typical interaction based on
   the MRB Control Package.

         MRB                                            MS
          |                                              |
          | A1. CONTROL (MRB subscription)               |
          |--------------------------------------------->|
          |                                   A2. 200 OK |
          |<---------------------------------------------|
          |                                              |--+ collect
          |                                              |  | requested
          |                                              |<-+ info
          |               B1. CONTROL (MRB notification) |
          |<---------------------------------------------|
          | B2. 200 OK                                   |
          |--------------------------------------------->|
          |                                              |
          .                                              .
          .                                              .
          |                                              |
          |                                              |--+ collect
          |                                              |  | up-to-date
          |                                              |<-+ info
          |               C1. CONTROL (MRB notification) |
          |<---------------------------------------------|
          | C2. 200 OK                                   |
          |--------------------------------------------->|
          |                                              |
          .                                              .
          .                                              .
          |                                              |
          | D1. CONTROL (Update MRB subscription)        |
          |--------------------------------------------->|
          |                                   D2. 200 OK |
          |<---------------------------------------------|
          |                                              |
          .                                              .
          .                                              .

    Figure 47: Media Resource Brokering: Subscription and Notification

   In this example, the MRB subscribes for information at the specified
   MS, and events are triggered on a regular, negotiated basis.  All of
   these messages flow through the Control Channel, as do all of the
   messages discussed in this document.  The framework transaction steps
   are as follows:

   o  The MRB sends a new CONTROL message (A1) addressed to the MRB
      package (mrb-publish/1.0); it is a subscription for information
      (<subscription>), and the MRB is asking to be notified at least
      every 10 minutes (<minfrequency>) or, if required, every 30
      seconds at maximum.  The subscription must last 30 minutes
      (<expires>), after which no additional notifications must be sent.

   o  The MS acknowledges the request (A2) and sends notification of the
      success of the request in a 200 OK message (<mrbresponse>).

   o  The MS prepares and sends the first notification to the MRB (B1).
      As has been done with other packages, the notification has been
      sent as an MS-generated CONTROL message; it is a notification
      related to the request in the first message, because the 'id'
      (p0T65U) matches that request.  All of the information that the
      MRB subscribed for is provided in the payload.

   o  The MRB acknowledges the notification (B2) and uses the retrieved
      information to update its own information as part of its business
      logic.

   o  The previous step (the MRB acknowledges notifications and uses the
      retrieved information) repeats at the required frequency, with
      up-to-date information.

   o  After a while, the MRB updates its subscription (D1) to get more
      frequent updates (minfrequency=1, an update every second at
      least).  The MS accepts the update (D2), although it may adjust
      the frequency in the reply according to its policies (e.g., a
      lower rate, such as minfrequency=30).  The notifications continue,
      but at the newer rate; the expiration is also updated accordingly
      (600 seconds again, since the update refreshes it).

A1. MRB -> MS (CONTROL, publish request)
----------------------------------------
   CFW lidc30BZObiC CONTROL
   Control-Package: mrb-publish/1.0
   Content-Type: application/mrb-publish+xml
   Content-Length: 337

   <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
      <mrbrequest>
         <subscription action="create" seqnumber="1" id="p0T65U">
            <expires>60</expires>
            <minfrequency>600</minfrequency>
            <maxfrequency>30</maxfrequency>
         </subscription>
      </mrbrequest>
   </mrbpublish>


A2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
   CFW lidc30BZObiC 200
   Timeout: 10
   Content-Type: application/mrb-publish+xml
   Content-Length: 139

   <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
           <mrbresponse status="200" reason="OK: Request accepted"/>
   </mrbpublish>


B1. MRB <- MS (CONTROL, event notification from MS)
---------------------------------------------------
   CFW 03fff52e7b7a CONTROL
   Control-Package: mrb-publish/1.0
   Content-Type: application/mrb-publish+xml
   Content-Length: 4157

   <mrbpublish version="1.0"
             xmlns="urn:ietf:params:xml:ns:mrb-publish">
    <mrbnotification seqnumber="1" id="p0T65U">
        <media-server-id>a1b2c3d4</media-server-id>
        <supported-packages>
            <package name="msc-ivr/1.0"/>
            <package name="msc-mixer/1.0"/>
            <package name="mrb-publish/1.0"/>
            <package name="msc-example-pkg/1.0"/>
        </supported-packages>

        <active-rtp-sessions>
            <rtp-codec name="audio/basic">
                <decoding>10</decoding>
                <encoding>20</encoding>
            </rtp-codec>
        </active-rtp-sessions>
        <active-mixer-sessions>
            <active-mix conferenceid="7cfgs43">
                <rtp-codec name="audio/basic">
                    <decoding>3</decoding>
                    <encoding>3</encoding>
                </rtp-codec>
            </active-mix>
        </active-mixer-sessions>
        <non-active-rtp-sessions>
            <rtp-codec name="audio/basic">
                <decoding>50</decoding>
                <encoding>40</encoding>
            </rtp-codec>
        </non-active-rtp-sessions>
        <non-active-mixer-sessions>
            <non-active-mix available="15">
                <rtp-codec name="audio/basic">
                    <decoding>15</decoding>
                    <encoding>15</encoding>
                </rtp-codec>
            </non-active-mix>
        </non-active-mixer-sessions>
        <media-server-status>active</media-server-status>
        <supported-codecs>
            <supported-codec name="audio/basic">
                <supported-codec-package name="msc-ivr/1.0">
                    <supported-action>encoding</supported-action>
                    <supported-action>decoding</supported-action>
                </supported-codec-package>
                <supported-codec-package name="msc-mixer/1.0">
                    <supported-action>encoding</supported-action>
                    <supported-action>decoding</supported-action>
                </supported-codec-package>
            </supported-codec>
        </supported-codecs>

        <application-data>TestbedPrototype</application-data>
        <file-formats>
            <supported-format name="audio/x-wav">
                <supported-file-package>
                    msc-ivr/1.0
                </supported-file-package>
            </supported-format>
        </file-formats>
        <max-prepared-duration>
            <max-time max-time-seconds="3600">
                <max-time-package>msc-ivr/1.0</max-time-package>
            </max-time>
        </max-prepared-duration>
        <dtmf-support>
            <detect>
                <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
                <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
            </detect>
            <generate>
                <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
                <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
            </generate>
            <passthrough>
                <dtmf-type package="msc-ivr/1.0" name="RFC4733"/>
                <dtmf-type package="msc-mixer/1.0" name="RFC4733"/>
            </passthrough>
        </dtmf-support>
        <mixing-modes>
            <audio-mixing-modes>
                <audio-mixing-mode package="msc-ivr/1.0"> \
                     nbest \
                </audio-mixing-mode>
            </audio-mixing-modes>
            <video-mixing-modes activespeakermix="true" vas="true">
                <video-mixing-mode package="msc-mixer/1.0"> \
                     single-view \
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer/1.0"> \
                     dual-view \
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer/1.0"> \
                     dual-view-crop \
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer/1.0"> \
                     dual-view-2x1 \
                </video-mixing-mode>

                <video-mixing-mode package="msc-mixer/1.0"> \
                     dual-view-2x1-crop \
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer/1.0"> \
                     quad-view \
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer/1.0"> \
                     multiple-5x1 \
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer/1.0"> \
                     multiple-3x3 \
                </video-mixing-mode>
                <video-mixing-mode package="msc-mixer/1.0"> \
                     multiple-4x4 \
                </video-mixing-mode>
            </video-mixing-modes>
        </mixing-modes>
        <supported-tones>
            <supported-country-codes>
                <country-code package="msc-ivr/1.0">GB</country-code>
                <country-code package="msc-ivr/1.0">IT</country-code>
                <country-code package="msc-ivr/1.0">US</country-code>
            </supported-country-codes>
            <supported-h248-codes>
                <h248-code package="msc-ivr/1.0">cg/*</h248-code>
                <h248-code package="msc-ivr/1.0">biztn/ofque</h248-code>
                <h248-code package="msc-ivr/1.0">biztn/erwt</h248-code>
                <h248-code package="msc-mixer/1.0">conftn/*</h248-code>
            </supported-h248-codes>
        </supported-tones>
        <file-transfer-modes>
            <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
        </file-transfer-modes>
        <asr-tts-support>
            <asr-support>
                <language xml:lang="en"/>
            </asr-support>
            <tts-support>
                <language xml:lang="en"/>
            </tts-support>
        </asr-tts-support>
        <vxml-support>
            <vxml-mode package="msc-ivr/1.0" support="rfc6231"/>
        </vxml-support>

        <media-server-location>
            <civicAddress xml:lang="it">
                <country>IT</country>
                <A1>Campania</A1>
                <A3>Napoli</A3>
                <A6>Via Claudio</A6>
                <HNO>21</HNO>
                <LMK>University of Napoli Federico II</LMK>
                <NAM>Dipartimento di Informatica e Sistemistica</NAM>
                <PC>80210</PC>
            </civicAddress>
        </media-server-location>
        <label>TestbedPrototype-01</label>
        <media-server-address>
            sip:MediaServer@ms.example.net
        </media-server-address>
        <encryption/>
    </mrbnotification>
   </mrbpublish>


B2. MRB -> MS (200 to CONTROL)
------------------------------
   CFW 03fff52e7b7a 200


(C1 and C2 omitted for brevity)


D1. MRB -> MS (CONTROL, publish request)
----------------------------------------
CFW pyu788fc32wa CONTROL
Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml
Content-Length: 342

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
    <mrbrequest>
        <subscription action="update" seqnumber="2" id="p0T65U">
            <expires>600</expires>
            <minfrequency>1</minfrequency>
        </subscription>
    </mrbrequest>
</mrbpublish>

D2. MRB <- MS (200 to CONTROL, request accepted)
------------------------------------------------
CFW pyu788fc32wa 200
Timeout: 10
Content-Type: application/mrb-publish+xml
Content-Length: 332

<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
    <mrbresponse status="200" reason="OK: Request accepted">
        <subscription action="create" seqnumber="2" id="p0T65U">
            <expires>600</expires>
            <minfrequency>30</minfrequency>
        </subscription>
    </mrbresponse>
</mrbpublish>

7.2.  Consumer Interface

   Whereas the Publishing interface is used by an MS to publish its
   functionality and up-to-date information to an MRB, the Consumer
   interface is used by an interested AS to access a resource.  An AS
   can use the Consumer interface to contact an MRB and describe the
   resources it needs.  The MRB then replies with the needed
   information: specifically, the address of an MS that is capable of
   meeting the requirements.

   However, unlike the Publishing interface, the Consumer interface is
   not specified as a Control Package.  Rather, it is conceived as an
   XML-based protocol that can be transported by means of either HTTP or
   SIP, as will be shown in the following sections.

   As specified in [RFC6917], the Consumer interface can be involved in
   two topologies: Query mode and Inline mode.  In the Query mode
   (Section 7.2.1), the Consumer requests and responses are conveyed by
   means of HTTP.  Once the AS gets the answer, the usual MEDIACTRL
   interactions occur between the AS and the MS chosen by the MRB.  By
   contrast, in the Inline mode, the MRB is in the path between the AS
   and the pool of MS it is handling.  In this case, an AS can place
   Consumer requests using SIP as a transport, by means of a multipart
   payload (Section 7.2.2) containing the Consumer request itself and an
   SDP related either to the creation of a Control Channel or to a UAC
   media dialog.  This is called Inline-aware mode, since it assumes
   that the interested AS knows that an MRB is in place and knows how to
   talk to it.  The MRB is also conceived to work with AS that are
   unaware of its functionality, i.e., unaware of the Consumer
   interface.  In this kind of scenario, the Inline mode is still used,
   but with the AS thinking the MRB it is talking to is actually an MS.
   This approach is called Inline-unaware mode (Section 7.2.3).

7.2.1.  Query Mode

   As discussed in the previous section, in the Query mode the AS sends
   Consumer requests by means of HTTP.  Specifically, an HTTP POST is
   used to convey the request.  The MRB is assumed to send its response
   by means of an HTTP 200 OK reply.  Since a successful Consumer
   response contains information to contact a specific MS (the MS the
   MRB has deemed most capable of fulfilling the AS's requirements), an
   AS can subsequently directly contact the MS, as described in
   Section 5.  This means that in the Query mode the MRB acts purely as
   a locator, and then the AS and the MS can talk 1:1.

   Figure 48 presents a ladder diagram of a typical Consumer request in
   the Query topology:

     AS                                             MRB
      |                                              |
      | 1. HTTP POST (Consumer request)              |
      |--------------------------------------------->|
      |                                              |
      |                                              |
      |                                              |--+ Parse request
      |                                              |  | and see if any
      |                                              |<-+ MS applies
      |                                              |
      |                2. 200 OK (Consumer response) |
      |<---------------------------------------------|
      |                                              |
      |--+ Parse response and                        |
      |  | start session (SIP/COMEDIA/CFW)           |
      |<-+ with MS reported by MRB                   |
      |                                              |
      .                                              .
      .                                              .

              Figure 48: Media Resource Brokering: Query Mode

   In this example, the AS is interested in an MS meeting a defined set
   of requirements.  The MS must:

   1.  support both the IVR and Mixer packages.

   2.  provide at least 10 G.711 encoding/decoding RTP sessions for IVR
       purposes.

   3.  support HTTP-based streaming and support for the audio/x-wav file
       format in the IVR package.

   These requirements are properly formatted according to the MRB
   Consumer syntax.  The framework transaction steps are as follows:

   o  The AS sends an HTTP POST message to the MRB (1).  The payload is,
      of course, the Consumer request, which is reflected by the
      Content-Type header (application/mrb-consumer+xml).  The Consumer
      request (<mediaResourceRequest>, uniquely identified by its 'id'
      attribute set to the random value 'n3un93wd'), includes some
      general requirements (<generalInfo>) and some IVR-specific
      requirements (<ivrInfo>).  The general part of the requests
      contains the set of required packages (<packages>).  The
      IVR-specific section contains requirements concerning the number
      of required IVR sessions (<ivr-sessions>), the file formats that
      are to be supported (<file-formats>), and the required file
      transfer capabilities (<file-transfer-modes>).

   o  The MRB gets the request and parses it.  Then, according to its
      business logic, it realizes it can't find a single MS capable of
      targeting the request and as a consequence picks two MS instances
      that can handle 60 and 40 of the requested sessions, respectively.
      It prepares a Consumer response (2) to provide the AS with the
      requested information.  The response (<mediaResourceResponse>,
      which includes the same 'id' attribute as the request) indicates
      success (status=200) and includes the relevant information
      (<response-session-info>).  Specifically, the response includes
      transaction-related information (the same session-id and seq
      provided by the AS in its request, to allow proper request/
      response matching) together with information on the duration of
      the reservation (expires=3600, i.e., after an hour the request
      will expire) and the SIP addresses of the chosen MS.

   Note how the sequence number the MRB returned is not 1.  According to
   the MRB specification, this is the starting value to increment for
   the sequence number to be used in subsequent requests.  This means
   that should the AS want to update or remove the session it should use
   10 as a value for the sequence number in the related request.
   According to Section 12 of [RFC6917], this random value for the first
   sequence number is also a way to help prevent a malicious entity from
   messing with or disrupting another AS session with the MRB.  In fact,
   sequence numbers in requests and responses have to match, and failure
   to provide the correct sequence number would result in session
   failure and a 405 error message.

1. AS -> MRB (HTTP POST, Consumer request)
------------------------------------------
 POST /Mrb/Consumer HTTP/1.1
 Content-Length: 893
 Content-Type: application/mrb-consumer+xml
 Host: mrb.example.com:8080
 Connection: Keep-Alive
 User-Agent: Apache-HttpClient/4.0.1 (java 1.5)

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
    <mediaResourceRequest id="n3un93wd">
        <generalInfo>
            <packages>
                <package>msc-ivr/1.0</package>
                <package>msc-mixer/1.0</package>
            </packages>
        </generalInfo>
        <ivrInfo>
            <ivr-sessions>
                <rtp-codec name="audio/basic">
                    <decoding>100</decoding>
                    <encoding>100</encoding>
                </rtp-codec>
            </ivr-sessions>
            <file-formats>
                <required-format name="audio/x-wav"/>
            </file-formats>
            <file-transfer-modes>
                <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
            </file-transfer-modes>
        </ivrInfo>
    </mediaResourceRequest>
 </mrbconsumer>


2. AS <- MRB (200 to POST, Consumer response)
---------------------------------------------
 HTTP/1.1 200 OK
 X-Powered-By: Servlet/2.5
 Server: Sun GlassFish Communications Server 1.5
 Content-Type: application/mrb-consumer+xml;charset=ISO-8859-1
 Content-Length: 1146
 Date: Thu, 28 Jul 2011 10:34:45 GMT

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <mrbconsumer version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-consumer">
    <mediaResourceResponse reason="Resource found" status="200"
                           id="n3un93wd">
        <response-session-info>
            <session-id>z603G3yaUzM8</session-id>
            <seq>9</seq>
            <expires>3600</expires>
            <media-server-address
                              uri="sip:MediaServer@ms.example.com:5080">
                <ivr-sessions>
                    <rtp-codec name="audio/basic">
                        <decoding>60</decoding>
                        <encoding>60</encoding>
                    </rtp-codec>
                </ivr-sessions>
            </media-server-address>
            <media-server-address
                       uri="sip:OtherMediaServer@pool.example.net:5080">
                <ivr-sessions>
                    <rtp-codec name="audio/basic">
                        <decoding>40</decoding>
                        <encoding>40</encoding>
                    </rtp-codec>
                </ivr-sessions>
            </media-server-address>
        </response-session-info>
    </mediaResourceResponse>
 </mrbconsumer>

   For the sake of conciseness, the subsequent steps are not presented.
   They are very trivial, since they basically consist of the AS issuing
   a COMEDIA negotiation with either of the obtained MS, as already
   presented in Section 5.  The same can be said with respect to
   attaching UAC media dialogs.  In fact, since after the Query the
   AS<->MS interaction becomes 1:1, UAC media dialogs can be redirected
   directly to the proper MS using the 3PCC approach, e.g., as shown in
   Figure 10.

7.2.2.  Inline-Aware Mode

   Unlike the Query mode, in the Inline-Aware MRB Mode (IAMM) the AS
   sends Consumer requests by means of SIP.  Of course, saying that the
   transport changes from HTTP to SIP is not as trivial as it seems.  In
   fact, HTTP and SIP behave in very different ways, and this is
   reflected in the way the Inline-aware mode is conceived.

   An AS willing to issue a Consumer request by means of SIP has to do
   so by means of an INVITE.  As specified in [RFC6917], the payload of
   the INVITE can't contain only the Consumer request itself.  In fact,
   the Consumer request is assumed to be carried within a SIP
   transaction.  A Consumer session is not strictly associated with the
   lifetime of any SIP transaction, meaning that Consumer requests
   belonging to the same session may be transported over different SIP
   messages; therefore, a hangup on any of these SIP dialogs would not
   affect a Consumer session.

   That said, as documented in [RFC6230], [RFC6917] envisages two kinds
   of SIP dialogs over which a Consumer request may be sent: a SIP
   control dialog (a SIP dialog sent by the AS in order to set up a
   Control Channel) and a UAC media dialog (a SIP dialog sent by the AS
   in order to attach a UAC to an MS).  In both cases, the AS would
   prepare a multipart/mixed payload to achieve both ends, i.e.,
   receiving a reply to its Consumer request and effectively carrying on
   the negotiation described in the SDP payload.

   The behaviors in the two cases, which are called the CFW-based
   approach and the media dialog-based approach, respectively, are only
   slightly different, but both will be presented to clarify how they
   could be exploited.  To make things clearer for the reader, the same
   Consumer request as the Consumer request presented in the Query mode
   will be sent, in order to clarify how the behavior of the involved
   parties may differ.

7.2.2.1.  Inline-Aware Mode: CFW-Based Approach

   Figure 49 presents a ladder diagram of a typical Consumer request in
   the CFW-based Inline-aware topology:

   AS                      MRB                          MS
    |                       |                           |
    | 1. INVITE             |                           |
    | (multipart/mixed:     |                           |
    |  application/cfw,     |                           |
    |  application/mrb-consumer+xml)                    |
    |---------------------->|                           |
    |       2. 100 (Trying) |                           |
    |<----------------------|                           |
    |                       |--+ Extract SDP and        |
    |                       |  | MRB payloads; handle   |
    |                       |<-+ Consumer request to    |
    |                       |    pick MS                |
    |                       |                           |

    |                       | 3. INVITE                 |
    |                       | (application/cfw from 1.) |
    |                       |-------------------------->|
    |                       |           4. 100 (Trying) |
    |                       |<--------------------------|
    |                       |                           |--+ Negotiate
    |                       |                           |  | CFW Control
    |                       |                           |<-+ Channel
    |                       |                 5. 200 OK |
    |                       | (application/cfw from MS) |
    |                       |<--------------------------|
    |                       | 6. ACK                    |
    |                       |-------------------------->|
    |        Prepare new +--|                           |
    |       payload with |  |                           |
    |    SDP from MS and +->|                           |
    |     Consumer reply    |                           |
    |                       |                           |
    |             7. 200 OK |                           |
    |     (multipart/mixed: |                           |
    |      application/cfw from MS,                     |
    |      application/mrb-consumer+xml)                |
    |<----------------------|                           |
    | 8. ACK                |                           |
    |---------------------->|                           |
    |                       |                           |
    |--+ Read Consumer      |                           |
    |  | reply and use SDP  |                           |
    |<-+ to create CFW Chn. |                           |
    |                       |                           |
    |                                                   |
    |<<############## TCP CONNECTION #################>>|
    |                                                   |
    | CFW SYNC                                          |
    |++++++++++++++++++++++++++++++++++++++++++++++++++>|
    |                                                   |
    .                       .                           .
    .                       .                           .

     Figure 49: Media Resource Brokering: CFW-Based Inline-Aware Mode

   To make the scenario easier to understand, we assume that the AS is
   interested in exactly the same set of requirements as those presented
   in Section 7.2.1.  This means that the Consumer request originated by
   the AS will be the same as before, with only the transport/topology
   changing.

   Please note that to make the protocol contents easier to read, a
   simple 'Part' is used whenever a boundary for a multipart/mixed
   payload is provided, instead of the actual boundary that would be
   inserted in the SIP messages.

   The framework transaction steps (for simplicity's sake, only the
   payloads, and not the complete SIP transactions, are reported) are as
   follows:

1. AS -> MRB (INVITE multipart/mixed)
-------------------------------------
   [..]
   Content-Type: multipart/mixed;boundary="Part"

   --Part
   Content-Type: application/sdp

   v=0
   o=- 2890844526 2890842807 IN IP4 as.example.com
   s=MediaCtrl
   c=IN IP4 as.example.com
   t=0 0
   m=application 48035 TCP cfw
   a=connection:new
   a=setup:active
   a=cfw-id:vF0zD4xzUAW9

   --Part
   Content-Type: application/mrb-consumer+xml

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <mrbconsumer version="1.0"
                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
     <mediaResourceRequest id="fr34asx1">
        <generalInfo>
            <packages>
                <package>msc-ivr/1.0</package>
                <package>msc-mixer/1.0</package>
            </packages>
        </generalInfo>
        <ivrInfo>
            <ivr-sessions>
                <rtp-codec name="audio/basic">
                    <decoding>100</decoding>
                    <encoding>100</encoding>
                </rtp-codec>
            </ivr-sessions>

            <file-formats>
                <required-format name="audio/x-wav"/>
            </file-formats>
            <file-transfer-modes>
                <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
            </file-transfer-modes>
        </ivrInfo>
     </mediaResourceRequest>
   </mrbconsumer>

   --Part


3. MRB -> MS (INVITE SDP only)
------------------------------
   [..]
   Content-Type: application/sdp

   v=0
   o=- 2890844526 2890842807 IN IP4 as.example.com
   s=MediaCtrl
   c=IN IP4 as.example.com
   t=0 0
   m=application 48035 TCP cfw
   a=connection:new
   a=setup:active
   a=cfw-id:vF0zD4xzUAW9


5. MRB <- MS (200 OK SDP)
-------------------------
   [..]
   Content-Type: application/sdp

   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:vF0zD4xzUAW9

7. AS <- MRB (200 OK multipart/mixed)
-------------------------------------
   [..]
   Content-Type: multipart/mixed;boundary="Part"

   --Part
   Content-Type: application/sdp

   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:vF0zD4xzUAW9

   --Part
   Content-Type: application/mrb-consumer+xml

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <mrbconsumer version="1.0"
                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
     <mediaResourceResponse reason="Resource found" status="200"
                            id="fr34asx1">
        <response-session-info>
            <session-id>z603G3yaUzM8</session-id>
            <seq>9</seq>
            <expires>3600</expires>
            <media-server-address
                              uri="sip:MediaServer@ms.example.com:5080">
                <connection-id>32pbdxZ8:KQw677BF</connection-id>
                <ivr-sessions>
                    <rtp-codec name="audio/basic">
                        <decoding>60</decoding>
                        <encoding>60</encoding>
                    </rtp-codec>
                </ivr-sessions>
            </media-server-address>

            <media-server-address
                       uri="sip:OtherMediaServer@pool.example.net:5080">
                <ivr-sessions>
                    <rtp-codec name="audio/basic">
                        <decoding>40</decoding>
                        <encoding>40</encoding>
                    </rtp-codec>
                </ivr-sessions>
            </media-server-address>
        </response-session-info>
     </mediaResourceResponse>
   </mrbconsumer>

   --Part

   The sequence diagram and the dumps effectively show the different
   approach with respect to the Query mode.  The SIP INVITE sent by the
   AS (1.) includes both a Consumer request (the same as before) and an
   SDP to negotiate a CFW channel with an MS.  The MRB takes care of the
   request exactly as before (provisioning two MS instances) but with a
   remarkable difference: first of all, it picks one of the two MS
   instances on behalf of the AS (negotiating the Control Channel in
   steps 3 to 6) and only then replies to the AS with both the MS side
   of the SDP negotiation (with information on how to set up the Control
   Channel) and the Consumer response itself.

   The Consumer response is also slightly different in the first place.
   In fact, as can be seen in 7., there's an additional element
   (<connection-id>) that the MRB has added to the message.  This
   element contains the 'connection-id' that the AS and MS would have
   built out of the 'From' and 'To' tags as explained in Section 6, had
   the AS contacted the MS directly.  Since the MRB has actually done
   the negotiation on behalf of the AS, without this information the AS
   and MS would refer to different connectionid attributes to target the
   same dialog, thus causing the CFW protocol not to behave as expected.
   This aspect will be more carefully described in the next section (for
   the media dialog-based approach), since the 'connection-id' attribute
   is strictly related to media sessions.

   As before, for the sake of conciseness the subsequent steps of the
   previous transaction are quite trivial and therefore are not
   presented.  In fact, as shown in the flow, the SIP negotiation has
   resulted in both the AS and the chosen MS negotiating a Control
   Channel.  This means that the AS is only left to instantiate the
   Control Channel and send CFW requests according to its application
   logic.

   It is worthwhile to highlight the fact that, as in the Query example,
   the AS gets the addresses of both of the chosen MS in this example as
   well, since a Consumer transaction has taken place.  This means that,
   just as in the Query case, any UAC media dialog can be redirected
   directly to the proper MS using the 3PCC approach, e.g., as shown in
   Figure 10, rather than again using the MRB as a Proxy/B2BUA.  Of
   course, a separate SIP control dialog would be needed before
   attempting to use the second MS instance.

7.2.2.2.  Inline-Aware Mode: Media Dialog-Based Approach

   There's a second way to take advantage of the IAMM mode, i.e.,
   exploiting SIP dialogs related to UAC media dialogs as 'vessels' for
   Consumer messages.  As will be made clearer in the following sequence
   diagram and protocol dumps, this scenario does not differ much from
   the scenario presented in Section 7.2.2.1 with respect to the
   Consumer request/response, but it may be useful to compare these two
   scenarios and show how they may differ with respect to the management
   of the media dialog itself and any CFW Control Channel that may be
   involved.

   Figure 50 presents a ladder diagram of a typical Consumer request in
   the media dialog-based Inline-aware topology:

   UAC              AS                     MRB                        MS
    |               |                       |                          |
    | 1. INVITE     |                       |                          |
    | (audio/video) |                       |                          |
    |-------------->|                       |                          |
    | 2. 100 Trying |                       |                          |
    |<--------------|                       |                          |
    |               | 3. INVITE             |                          |
    |               | (multipart/mixed:     |                          |
    |               |  audio/video from 1., |                          |
    |               |  application/mrb-consumer+xml)                   |
    |               |---------------------->|                          |
    |               |       4. 100 (Trying) |                          |
    |               |<----------------------|                          |
    |               |                       |--+ Extract SDP and       |
    |               |                       |  | MRB payloads; handle  |
    |               |                       |<-+ Consumer request to   |
    |               |                       |    pick Media Servers    |
    |               |                       |                          |
    |               |                       | 5. INVITE                |
    |               |                       | (audio/video from 3.)    |
    |               |                       |------------------------->|

    |               |                       |          6. 100 (Trying) |
    |               |                       |<-------------------------|
    |               |                       |                       +--|
    |               |                       |   Handle media dialog |  |
    |               |                       |       (connection-id) +->|
    |               |                       |                          |
    |               |                       |                7. 200 OK |
    |               |                       |    (audio/video from MS) |
    |               |                       |<-------------------------|
    |               |                       | 8. ACK                   |
    |               |                       |------------------------->|
    |               |        Prepare new +--|                          |
    |               |       payload with |  |                          |
    |               |    SDP from MS and +->|                          |
    |               |     Consumer reply    |                          |
    |               |                       |                          |
    |               |             9. 200 OK |                          |
    |               |     (multipart/mixed: |                          |
    |               |      audio/video from MS,                        |
    |               |      application/mrb-consumer+xml)               |
    |               |<----------------------|                          |
    |               | 10. ACK               |                          |
    |               |---------------------->|                          |
    |               |                       |                          |
    |               |--+ Read Consumer      |                          |
    |               |  | reply and send     |                          |
    |               |<-+ SDP back to UAC    |                          |
    |    11. 200 OK |                       |                          |
    |(audio/video from MS)                  |                          |
    |<--------------|                       |                          |
    | 12. ACK       |                       |                          |
    |-------------->|                       |                          |
    |               |                       |                          |
    |<<*************************** RTP ******************************>>|
    |               |                       |                          |
    |               |--+ Negotiate          |                          |
    |               |  | CFW channel        |                          |
    |               |<-+ towards MS         |                          |
    |               |    (if needed)        |                          |
    .               .                       .                          .
    .               .                       .                          .
    |               |                       |                          |
    |               |<<############## TCP CONNECTION ################>>|
    |               |                                                  |

    |               | CFW SYNC                                         |
    |               |+++++++++++++++++++++++++++++++++++++++++++++++++>|
    |               |                                                  |
    .               .                       .                          .
    .               .                       .                          .

          Figure 50: Media Resource Brokering: Media Dialog-Based
                             Inline-Aware Mode

   To make the scenario easier to understand, we assume that the AS is
   interested in exactly the same set of requirements as those presented
   in Section 7.2.1.  This means that the Consumer request originated by
   the AS will be the same as before, with only the transport/topology
   changing.

   Again, please note that to make the protocol contents easier to read,
   a simple 'Part' is used whenever a boundary for a multipart/mixed
   payload is provided, instead of the actual boundary that would be
   inserted in the SIP messages.

   The framework transaction steps (for simplicity's sake, only the
   relevant headers and payloads, and not the complete SIP transactions,
   are reported) are as follows:

1. UAC -> AS (INVITE with media SDP)
------------------------------------
   [..]
   From: <sip:lminiero@users.example.com>;tag=1153573888
   To: <sip:mediactrlDemo@as.example.com>
   [..]
   Content-Type: application/sdp

   v=0
   o=lminiero 123456 654321 IN IP4 203.0.113.2
   s=A conversation
   c=IN IP4 203.0.113.2
   t=0 0
   m=audio 7078 RTP/AVP 0 3 8 101
   a=rtpmap:0 PCMU/8000/1
   a=rtpmap:3 GSM/8000/1
   a=rtpmap:8 PCMA/8000/1
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-11
   m=video 9078 RTP/AVP 98

3. AS -> MRB (INVITE multipart/mixed)
-------------------------------------
   [..]
   From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
   To: <sip:Mrb@mrb.example.org>
   [..]
   Content-Type: multipart/mixed;boundary="Part"

   --Part
   Content-Type: application/sdp

   v=0
   o=lminiero 123456 654321 IN IP4 203.0.113.2
   s=A conversation
   c=IN IP4 203.0.113.2
   t=0 0
   m=audio 7078 RTP/AVP 0 3 8 101
   a=rtpmap:0 PCMU/8000/1
   a=rtpmap:3 GSM/8000/1
   a=rtpmap:8 PCMA/8000/1
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-11
   m=video 9078 RTP/AVP 98

   --Part
   Content-Type: application/mrb-consumer+xml

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <mrbconsumer version="1.0"
                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
    <mediaResourceRequest id="bnv3xc45">
        <generalInfo>
            <packages>
                <package>msc-ivr/1.0</package>
                <package>msc-mixer/1.0</package>
            </packages>
        </generalInfo>
        <ivrInfo>
            <ivr-sessions>
                <rtp-codec name="audio/basic">
                    <decoding>100</decoding>
                    <encoding>100</encoding>
                </rtp-codec>
            </ivr-sessions>
            <file-formats>
                <required-format name="audio/x-wav"/>
            </file-formats>

            <file-transfer-modes>
                <file-transfer-mode package="msc-ivr/1.0" name="HTTP"/>
            </file-transfer-modes>
        </ivrInfo>
    </mediaResourceRequest>
   </mrbconsumer>

   --Part


5. MRB -> MS (INVITE SDP only)
------------------------------
   [..]
   From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
   To: <sip:MediaServer@ms.example.com:5080>
   [..]
   Content-Type: application/sdp

   v=0
   o=lminiero 123456 654321 IN IP4 203.0.113.2
   s=A conversation
   c=IN IP4 203.0.113.2
   t=0 0
   m=audio 7078 RTP/AVP 0 3 8 101
   a=rtpmap:0 PCMU/8000/1
   a=rtpmap:3 GSM/8000/1
   a=rtpmap:8 PCMA/8000/1
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-11
   m=video 9078 RTP/AVP 98


7. MRB <- MS (200 OK SDP)
-------------------------
   [..]
   From: <sip:Mrb@mrb.example.org:5060>;tag=32pbdxZ8
   To: <sip:MediaServer@ms.example.com:5080>;tag=KQw677BF
   [..]
   Content-Type: application/sdp

   v=0
   o=lminiero 123456 654322 IN IP4 203.0.113.1
   s=MediaCtrl
   c=IN IP4 203.0.113.1
   t=0 0
   m=audio 63442 RTP/AVP 0 3 8 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:3 GSM/8000

   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15
   a=ptime:20
   a=label:7eda834
   m=video 33468 RTP/AVP 98
   a=rtpmap:98 H263-1998/90000
   a=fmtp:98 CIF=2
   a=label:0132ca2


9. AS <- MRB (200 OK multipart/mixed)
-------------------------------------
   [..]
   From: <sip:ApplicationServer@as.example.com>;tag=fd4fush5
   To: <sip:Mrb@mrb.example.org>;tag=117652221
   [..]
   Content-Type: multipart/mixed;boundary="Part"

   --Part
   Content-Type: application/sdp

   v=0
   o=lminiero 123456 654322 IN IP4 203.0.113.1
   s=MediaCtrl
   c=IN IP4 203.0.113.1
   t=0 0
   m=audio 63442 RTP/AVP 0 3 8 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:3 GSM/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15
   a=ptime:20
   a=label:7eda834
   m=video 33468 RTP/AVP 98
   a=rtpmap:98 H263-1998/90000
   a=fmtp:98 CIF=2
   a=label:0132ca2

   --Part
   Content-Type: application/mrb-consumer+xml

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <mrbconsumer version="1.0"
                xmlns="urn:ietf:params:xml:ns:mrb-consumer" >
    <mediaResourceResponse reason="Resource found" status="200"
                           id="bnv3xc45">
        <response-session-info>
            <session-id>z1skKYZQ3eFu</session-id>
            <seq>9</seq>
            <expires>3600</expires>
            <media-server-address
                              uri="sip:MediaServer@ms.example.com:5080">
                <connection-id>32pbdxZ8:KQw677BF</connection-id>
                <ivr-sessions>
                    <rtp-codec name="audio/basic">
                        <decoding>60</decoding>
                        <encoding>60</encoding>
                    </rtp-codec>
                </ivr-sessions>
            </media-server-address>
            <media-server-address
                       uri="sip:OtherMediaServer@pool.example.net:5080">
                <ivr-sessions>
                    <rtp-codec name="audio/basic">
                        <decoding>40</decoding>
                        <encoding>40</encoding>
                    </rtp-codec>
                </ivr-sessions>
            </media-server-address>
        </response-session-info>
    </mediaResourceResponse>
   </mrbconsumer>

   --Part


11. UAC <- AS (200 OK SDP)
--------------------------
   [..]
   From: <sip:lminiero@users.example.com>;tag=1153573888
   To: <sip:mediactrlDemo@as.example.com>;tag=bcd47c32
   [..]
   Content-Type: application/sdp

   v=0
   o=lminiero 123456 654322 IN IP4 203.0.113.1
   s=MediaCtrl
   c=IN IP4 203.0.113.1
   t=0 0

   m=audio 63442 RTP/AVP 0 3 8 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:3 GSM/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15
   a=ptime:20
   a=label:7eda834
   m=video 33468 RTP/AVP 98
   a=rtpmap:98 H263-1998/90000
   a=fmtp:98 CIF=2
   a=label:0132ca2

   The first obvious difference is that the first INVITE (1.) is not
   originated by the AS itself (the AS was willing to set up a Control
   Channel in the previous example) but by an authorized UAC (e.g., to
   take advantage of a media service provided by the AS).  As such, the
   first INVITE only contains an SDP to negotiate an audio and video
   channel.  The AS in its business logic needs to attach this UAC to an
   MS according to some specific requirements (e.g., the called URI is
   associated to a specific service) and as such prepares a Consumer
   request to be sent to the MRB in order to obtain a valid MS for that
   purpose.  As before, the Consumer request is sent together with the
   SDP to the MRB (3.).  The MRB extracts the Consumer payload and takes
   care of it as usual; it picks two MS instances and attaches the UAC
   to the first MS instance (5.).  Once the MS has successfully
   negotiated the audio and video streams (7.), the MRB takes note of
   the 'connection-id' associated with this call (which will be needed
   afterwards in order to manipulate the audio and video streams for
   this user) and sends back to the AS both the SDP returned by the MS
   and the Consumer response (9.).  The AS extracts the Consumer
   response and takes note of both the MS instances it has been given
   and the connection-id information.  It then completes the scenario by
   sending back to the UAC the SDP returned by the MS (11.).

   At this point, the UAC has successfully been attached to an MS.  The
   AS only needs to set up a Control Channel to that MS, if needed.
   This step may not be required, especially if the Consumer request is
   an update to an existing session rather than the preparation of a new
   session.  Assuming that a Control Channel towards that MS doesn't
   exist yet, the AS creates it as usual by sending an INVITE directly
   to the MS for which it has an address.  Once done with that, it can
   start manipulating the audio and video streams of the UAC.  To do so,
   it refers to the <connection-id> element as reported by the MRB,
   rather than relying on the <connection-id> element that it is aware
   of.  In fact, the AS is aware of a connection-id value (fd4fush5:
   117652221, built out of the messages exchanged with the MRB), while
   the MS is aware of another (32pbdxZ8:KQw677BF, built out of the

   MRB-MS interaction).  The right connection-id is of course the one
   the MS is aware of, and as such the AS refers to that connection-id,
   which the MRB added to the Consumer response just for that purpose.

7.2.3.  Inline-Unaware Mode

   Whereas in the Inline-aware mode the AS knows it is sending an INVITE
   to an MRB and not to an MS, and acts accordingly (using the
   multipart/mixed payload to query for an MS able to fulfill its
   requirements), in the Inline-Unaware MRB Mode (IUMM) the AS does not
   distinguish an MRB from an MS.  This means that an MRB-unaware AS
   having access to an MRB talks to it as if it were a generic MEDIACTRL
   MS: i.e., the AS negotiates a Control Channel directly with the MRB
   and attaches its media dialogs there as well.  Of course, since the
   MRB doesn't provide any MS functionality by itself, it must act as a
   Proxy/B2BUA between the AS and an MS for both the Control Channel
   dialog and the media dialogs.  According to implementation or
   deployment choices, simple redirects could also be exploited for that
   purpose.

   The problem is that without any Consumer request being placed by the
   MRB-unaware AS the MRB can't rely on AS-originated directives to pick
   one MS rather than another.  In fact, the MRB can't know what the AS
   is looking for.  The MRB is then assumed to pick one according to its
   logic, which is implementation specific.

   Figure 51 presents a ladder diagram of a typical Consumer request in
   the Inline-unaware topology:

   AS                      MRB                          MS
    |                       |                           |
    | 1. INVITE             |                           |
    | (application/cfw)     |                           |
    |---------------------->|                           |
    |       2. 100 (Trying) |                           |
    |<----------------------|                           |
    |                       |--+ Pick an MS             |
    |                       |  | and redirect           |
    |                       |<-+ INVITE there           |
    |                       |                           |
    |                       | 3. INVITE                 |
    |                       | (application/cfw from 1.) |
    |                       |-------------------------->|
    |                       |           4. 100 (Trying) |
    |                       |<--------------------------|
    |                       |                           |--+ Negotiate
    |                       |                           |  | CFW Control
    |                       |                           |<-+ Channel
    |                       |                 5. 200 OK |
    |                       | (application/cfw from MS) |
    |                       |<--------------------------|
    |                       | 6. ACK                    |
    |                       |-------------------------->|
    |                       |                           |
    |             7. 200 OK |                           |
    |(application/cfw from MS)                          |
    |<----------------------|                           |
    | 8. ACK                |                           |
    |---------------------->|                           |
    |                       |                           |
    |                                                   |
    |<<############## TCP CONNECTION #################>>|
    |                                                   |
    | CFW SYNC                                          |
    |++++++++++++++++++++++++++++++++++++++++++++++++++>|
    |                                                   |
    .                       .                           .
    .                       .                           .

         Figure 51: Media Resource Brokering: Inline-Unaware Mode

   As can be seen in the diagram, in this topology the MRB basically
   acts as a 3PCC between the AS and the chosen MS.

   The same can be said with respect to attaching UAC media dialogs.
   The MRB remembers the MS it has chosen for the AS, and for every UAC
   media dialog the AS tries to attach to the MRB, it makes sure that it
   is somehow actually redirected to the MS.

   No content for the presented messages is provided in this section, as
   in the IUMM mode no Consumer transaction is involved.  In this
   example, a simple [RFC6230] Control Channel negotiation occurs where
   the MRB acts as an intermediary, that is, picking an MS for the AS
   according to some logic.  In this case, in fact, the AS does not
   support the MRB specification and so just tries to set up a Control
   Channel according to its own logic.

   It is worth pointing out that the MRB may actually enforce its
   decision about the MS to grant to the AS in different ways.
   Specifically, the sentence "redirect the INVITE" that is used in
   Figure 51 does not necessarily mean that a SIP 302 message should be
   used for that purpose.  A simple way to achieve this may be
   provisioning the unaware AS with different URIs, all actually
   transparently handled by the MRB itself; this would allow the MRB to
   simply map those URIs to different MS instances.  The SIP 'Contact'
   header may also be used by the MRB in a reply to an INVITE coming
   from an AS to provide the actual URI on which the chosen MS might be
   reached.  A motivation for such a discussion, and more details on
   this topic, are provided in Section 7.3.2.