tech-invite   World Map     

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

RFC 6917

 
 
 

Media Resource Brokering

Part 4 of 6, p. 58 to 83
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 58 
9.  Examples

   This section provides examples of both the Publish and Consumer
   interfaces.  Both the Query mode and In-line mode are addressed.

   Note that due to RFC formatting conventions, this section often
   splits HTTP, SIP/SDP, and CFW across lines whose content would exceed
   72 characters.  A backslash character marks where this line folding
   has taken place.  This backslash, and its trailing CRLF and
   whitespace, would not appear in the actual protocol contents.  Also
   note that the indentation of the XML content is only provided for
   readability: actual messages will follow strict XML syntax, which
   allows for but does not require indentation.

9.1.  Publish Example

   The following example assumes that a Control Channel has been
   established and synced as described in the Media Control Channel
   Framework ([RFC6230]).

Top      Up      ToC       Page 59 
   Figure 9 shows the subscription/notification mechanism the Publish
   interface is based on, as defined in Section 5.1.  The MRB subscribes
   for information at the Media Server (message A1.), and the Media
   Server accepts the subscription (A2.).  Notifications are triggered
   by the Media Server (B1.) and acknowledged by the MRB (B2.).

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

                Figure 9: Publish Example: Sequence Diagram

   The rest of this section includes a full dump of the messages
   associated with the previous sequence diagram, specifically:

   1.  the subscription (A1.), in an <mrbrequest> (CFW CONTROL);

   2.  the Media Server accepting the subscription (A2.), in an
       <mrbresponse> (CFW 200);

   3.  a notification (B1.), in an <mrbnotification> (CFW CONTROL);

   4.  the ack to the notification (B2.), in a framework-level 200
       message (CFW 200).

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

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
    <mrbrequest>
        <subscription action="create" seqnumber="1" id="p0T65U">
            <expires>600</expires>
            <minfrequency>20</minfrequency>
            <maxfrequency>20</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: 4226

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <mrbpublish version="1.0"
             xmlns="urn:ietf:params:xml:ns:mrb-publish">
    <mrbnotification seqnumber="1" id="QQ6J3c">
        <media-server-id>a1b2c3d4</media-server-id>
        <supported-packages>
            <package name="msc-ivr/1.0"/>
            <package name="msc-mixer/1.0"/>

Top      Up      ToC       Page 61 
            <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>

Top      Up      ToC       Page 62 
        <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>

Top      Up      ToC       Page 63 
                <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>

Top      Up      ToC       Page 64 
                <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:MS1@ms.example.net</media-server-address>
     <encryption/>
    </mrbnotification>
   </mrbpublish>


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

9.2.  Consumer Examples

   As specified in Section 5.2, the Consumer interface can be involved
   in two different modes: Query and In-line aware.  When in Query mode,
   Consumer messages are transported in HTTP messages: an example of
   such an approach is presented in Section 9.2.1.  When in In-line
   aware mode, messages are instead transported as part of SIP
   negotiations: considering that SIP negotiations may be related to
   either the creation of a Control Channel or to a User Agent Client
   (UAC) media dialog, two separate examples of such an approach are
   presented in Section 9.2.2.

9.2.1.  Query Example

   The following example assumes that the interested Application Server
   already knows the HTTP URL where an MRB is listening for Consumer
   messages.

Top      Up      ToC       Page 65 
   Figure 10 shows the HTTP-based transaction between the Application
   Server (AS, as shown in the figure) and the MRB.  The Application
   Server sends a Consumer request as payload of an HTTP POST message
   (1.), and the MRB provides an answer in an HTTP 200 OK message (2.).
   Specifically, as will be shown in the examples, the Application
   Server is interested in 100 IVR ports: the MRB finds two Media
   Servers that can satisfy the request (one providing 60 ports and the
   other providing 40 ports) and reports them to the Application Server.

     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 first MS reported by MRB             |
      |                                              |
      .                                              .
      .                                              .

           Figure 10: Consumer Example (Query): Sequence Diagram

   The rest of this section includes a full dump of the messages
   associated with the previous sequence diagram, specifically:

   1.  the Consumer request (1.), in a <mediaResourceRequest> (HTTP
       POST, Content-Type 'application/mrb-consumer+xml');

   2.  the Consumer response (2.), in a <mediaResourceResponse> (HTTP
       200 OK, Content-Type 'application/mrb-consumer+xml').

Top      Up      ToC       Page 66 
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.net: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="gh11x23v">
        <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>

Top      Up      ToC       Page 67 
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: 1133
Date: Mon, 12 Apr 2011 14:59:26 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="gh11x23v">
        <response-session-info>
            <session-id>5t3Y4IQ84gY1</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>

   As the example shows, the request and response are associated by
   means of the 'id' attribute (id="gh11x23v").  The MRB has picked '9'
   as the random sequence number that needs to be incremented by the
   Application Server for the subsequent request associated with the
   same session.

Top      Up      ToC       Page 68 
   The rest of the scenario is omitted for brevity.  After having
   received the 'mediaResourceResponse', the Application Server has the
   URIs of two Media Servers able to fulfill its media requirements and
   can start a control dialog with one or both of them.

9.2.2.  IAMM Examples

   Two separate examples are presented for the IAMM case: in fact, IAMM
   can take advantage of two different approaches with respect to the
   SIP dialogs to be exploited to carry Consumer messages, i.e., i) a
   SIP control dialog to create a Control Channel, and ii) a UAC media
   dialog to attach to a Media Server.  To make things clearer for the
   reader, the same Consumer request as the one presented in the Query
   mode will be sent, in order to clarify how the behavior of the
   involved parties may differ.

9.2.2.1.  IAMM Example: CFW-Based Approach

   The following example assumes that the interested Application Server
   already knows the SIP URI of an MRB.

   Figure 11 shows the first approach, i.e., SIP-based transactions
   between the Application Server, the MRB, and one Media Server that
   the MRB chooses from the two that are allocated to fulfill the
   request.  The diagram is more complex than before.  This is basically
   a scenario envisaging the MRB as a B2BUA.  The Application Server
   sends a SIP INVITE (1.) containing both a CFW-related SDP and a
   Consumer request (multipart body).  The MRB sends a provisional
   response to the Application Server (2.) and starts working on the
   request.  First of all, it makes use of the Consumer request from the
   Application Server to determine which Media Servers should be
   exploited.  Once the right Media Servers have been chosen (MS1 and
   MS2 in the example), the MRB sends a new SIP INVITE (3.) to one of
   the Media Servers (MS1 in the example) by just including the SDP part
   of the original request.  That Media Server negotiates this INVITE as
   specified in [RFC6230] (4., 5., 6.), providing the MRB with its own
   CFW-related SDP.  The MRB replies to the original Application Server
   INVITE preparing a SIP 200 OK with another multipart body (7.): this
   multipart body includes the Consumer response used by the MRB to
   determine the right Media Servers and the SDP returned by the Media
   Server (MS1) in (5.).  The Application Server finally acknowledges
   the 200 OK (8.), and can start a CFW connection towards that Media
   Server (MS1).  Since the MRB provided the Application Server with two
   Media Server instances to fulfill its requirements, the Application
   Server can use the URI in the <media-server-address> element in the
   <mediaResourceResponse> that describes the other Media Server to
   establish a CFW channel with that Media Server (MS2) as well.

Top      Up      ToC       Page 69 
   Please note that to ease the reading of the protocol contents 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.

  AS                     MRB                        MS1              MS2
  |                       |                           |                |
  | 1. INVITE             |                           |                |
  | (multipart/mixed)     |                           |                |
  |---------------------->|                           |                |
  |       2. 100 (Trying) |                           |                |
  |<----------------------|                           |                |
  |                       |--+ Extract SDP and        |                |
  |                       |  | MRB payloads; handle   |                |
  |                       |<-+ Consumer request to    |                |
  |                       |    pick MSs (MS1 and MS2) |                |
  |                       |                           |                |
  |                       | 3. INVITE                 |                |
  |                       | (only copy SDP from 1.)   |                |
  |                       |-------------------------->|                |
  |                       |           4. 100 (Trying) |                |
  |                       |<--------------------------|                |
  |                       |                           |--+ Negotiate   |
  |                       |                           |  | CFW Control |
  |                       |                           |<-+ Channel     |
  |                       |                 5. 200 OK |                |
  |                       |<--------------------------|                |
  |                       | 6. ACK                    |                |
  |                       |-------------------------->|                |
  |        Prepare new +--|                           |                |
  |       payload with |  |                           |                |
  |    SDP from MS and +->|                           |                |
  |     Consumer reply    |                           |                |
  |                       |                           |                |
  |             7. 200 OK |                           |                |
  |     (multipart/mixed) |                           |                |
  |<----------------------|                           |                |
  | 8. ACK                |                           |                |
  |---------------------->|                           |                |
  |                       |                           |                |
  |--+ Read Cons. reply   |                           |                |
  |  | and use SDP to     |                           |                |
  |<-+ create CFW Chn.    |                           |                |
  |                       |                           |                |
  |                                                   |                |
  |   Create TCP CFW channel towards MS1 (if needed)  |                |
  |-------------------------------------------------->|                |
  |                                                   |                |

Top      Up      ToC       Page 70 
  |<<############## TCP CONNECTION #################>>|                |
  |                                                   |                |
  | CFW SYNC                                          |                |
  |++++++++++++++++++++++++++++++++++++++++++++++++++>|                |
  |                                                   |                |
  .                       .                           .                .
  .                       .                           .                .
  |                                                   |                |
  |   Negotiate SIP control dialog with MS2                            |
  |<------------------------------------------------------------------>|
  |   Create TCP CFW channel towards MS2 as well (if needed)           |
  |------------------------------------------------------------------->|
  |                                                                    |
  |<<######################## TCP CONNECTION ########################>>|
  |                                                                    |
  | CFW SYNC                                                           |
  |+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>|
  |                                                                    |
  |                       |                           |                |
  .                       .                           .                .
  .                       .                           .                .

   Figure 11: Consumer Example (IAMM/Control Channel): Sequence Diagram

   The rest of this section includes an almost full trace of the
   messages associated with the previous sequence diagram.  Only the
   relevant SIP messages are shown (both the INVITEs and the 200 OKs),
   and only the relevant headers are preserved for brevity (Content-Type
   and multipart-related information).  Specifically:

   1.  the original INVITE (1.) containing both a CFW-related SDP
       (Connection-Oriented Media (COMEDIA) information to negotiate a
       new Control Channel) and a Consumer <mediaResourceRequest>;

   2.  the INVITE sent by the MRB (acting as a B2BUA) to the Media
       Server (3.), containing only the CFW-related SDP from the
       original INVITE;

   3.  the 200 OK sent by the Media Server back to the MRB (5.) to
       complete the CFW-related negotiation (SDP only);

   4.  the 200 OK sent by the MRB back to the Application Server in
       response to the original INVITE (7.), containing both the
       CFW-related information sent by the Media Server and a Consumer
       <mediaResourceRequest> documenting the MRB's decision to use that
       Media Server.

Top      Up      ToC       Page 71 
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
   a=ctrl-package:msc-mixer/1.0
   a=ctrl-package:msc-ivr/1.0

   =_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="pz78hnq1">
        <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>

Top      Up      ToC       Page 72 
   </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
   a=ctrl-package:msc-mixer/1.0
   a=ctrl-package:msc-ivr/1.0


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
   a=ctrl-package:msc-mixer/1.0
   a=ctrl-package:msc-ivr/1.0
   a=ctrl-package:mrb-publish/1.0
   a=ctrl-package:msc-example-pkg/1.0

Top      Up      ToC       Page 73 
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
   a=ctrl-package:msc-mixer/1.0
   a=ctrl-package:msc-ivr/1.0
   a=ctrl-package:mrb-publish/1.0
   a=ctrl-package:msc-example-pkg/1.0

   =_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="pz78hnq1">
        <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">

Top      Up      ToC       Page 74 
                        <decoding>40</decoding>
                        <encoding>40</encoding>
                    </rtp-codec>
                </ivr-sessions>
            </media-server-address>
        </response-session-info>
    </mediaResourceResponse>
   </mrbconsumer>

   =_Part

   As the previous example illustrates, the only difference in the
   response that the MRB provides to the Application Server is in the
   'connection-id' attribute that is added to the first allocated Media
   Server instance: this allows the Application Server to understand
   that the MRB has sent the CFW channel negotiation to that specific
   Media Server and that the connection-id to be used is the one
   provided.  This will be described in more detail in the following
   section for the media dialog-based approach.

   The continuation of the scenario (the Application Server connecting
   to MS1 to start the Control Channel and the related SYNC message, the
   Application Server connecting to MS2 as well later on, all the media
   dialogs being attached to either Media Server) is omitted for
   brevity.

9.2.2.2.  IAMM Example: Media Dialog-Based Approach

   The following example assumes that the interested Application Server
   already knows the SIP URI of an MRB.

   Figure 12 shows the second approach, i.e., SIP-based transactions
   between a SIP client, the Application Server, the MRB, and the Media
   Server that the MRB chooses.  The interaction is basically the same
   as previous examples (e.g., contents of the multipart body), but
   considering that a new party is involved in the communication, the
   diagram is slightly more complex than before.  As before, the MRB
   acts as a B2BUA.  A UAC sends a SIP INVITE to a SIP URI handled by
   the Application Server, since it is interested to its services (1.).
   The Application Server sends a provisional response (2.) and, since
   it doesn't have the resources yet, sends to the MRB a new SIP INVITE
   (3.) containing both the UAC media-related SDP and a Consumer request
   (multipart body).  The MRB sends a provisional response to the
   Application Server (4.) and starts working on the request.  First of
   all, it makes use of the Consumer request from the Application Server
   to determine which Media Servers should be chosen.  Once the Media
   Server has been chosen, the MRB sends a new SIP INVITE to one of the
   Media Servers by including the SDP part of the original request (5.).

Top      Up      ToC       Page 75 
   The Media Server negotiates this INVITE as specified in [RFC6230]
   (6., 7., 8.) to allocate the needed media resources to handle the new
   media dialog, eventually providing the MRB with its own media-related
   SDP.  The MRB replies to the original Application Server INVITE
   preparing a SIP 200 OK with a multipart body (9.): this multipart
   body includes the Consumer response from the MRB indicating the
   chosen Media Servers and the SDP returned by the Media Server in
   (7.).  The Application Server finally acknowledges the 200 OK (10.)
   and ends the scenario by eventually providing the UAC with the SDP it
   needs to set up the RTP channels with the chosen Media Server: a
   separate direct SIP control dialog may be initiated by the
   Application Server to the same Media Server in order to set up a
   Control Channel to manipulate the media dialog.

   As with the IAMM/Control Channel example in the prior section, this
   example has the MRB selecting Media Server resources across two Media
   Server instances.  The convention could be that the MRB sent the SIP
   INVITE to the first Media Server in the list provided to the
   Application Server in the Consumer response information.  For the
   sake of brevity, considerations related to connecting to the other
   Media Servers as well are omitted, since they have already been
   addressed in the previous section.

   Please note that to ease the reading of the protocol contents, 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.

Top      Up      ToC       Page 76 
 UAC              AS                     MRB                          MS
  |               |                       |                           |
  | 1. INVITE     |                       |                           |
  | (media SDP)   |                       |                           |
  |-------------->|                       |                           |
  | 2. 100 Trying |                       |                           |
  |<--------------|                       |                           |
  |               | 3. INVITE             |                           |
  |               | (multipart/mixed)     |                           |
  |               |---------------------->|                           |
  |               |       4. 100 (Trying) |                           |
  |               |<----------------------|                           |
  |               |                       |--+ Extract SDP and        |
  |               |                       |  | MRB payloads; handle   |
  |               |                       |<-+ Consumer request to    |
  |               |                       |    pick Media Servers     |
  |               |                       |                           |
  |               |                       | 5. INVITE                 |
  |               |                       | (only copy SDP from 3.)   |
  |               |                       |-------------------------->|
  |               |                       |           6. 100 (Trying) |
  |               |                       |<--------------------------|
  |               |                       |                        +--|
  |               |                       |    Handle media dialog |  |
  |               |                       |        (connection-id) +->|
  |               |                       |                           |
  |               |                       |                 7. 200 OK |
  |               |                       |<--------------------------|
  |               |                       | 8. ACK                    |
  |               |                       |-------------------------->|
  |               |        Prepare new +--|                           |
  |               |       payload with |  |                           |
  |               |    SDP from MS and +->|                           |
  |               |     Consumer reply    |                           |
  |               |                       |                           |
  |               |             9. 200 OK |                           |
  |               |     (multipart/mixed) |                           |
  |               |<----------------------|                           |
  |               | 10. ACK               |                           |
  |               |---------------------->|                           |
  |               |                       |                           |
  |               |--+ Read Cons. reply   |                           |
  |               |  | and send SDP       |                           |
  |               |<-+ back to UAC        |                           |
  |    11. 200 OK |                       |                           |
  |<--------------|                       |                           |
  | 12. ACK       |                       |                           |
  |-------------->|                       |                           |

Top      Up      ToC       Page 77 
  |               |                       |                           |
  |<<*************************** RTP *******************************>>|
  |               |                       |                           |
  |               |--+ Negotiate          |                           |
  |               |  | CFW channel        |                           |
  |               |<-+ towards MS         |                           |
  |               |    (if needed)        |                           |
  .               .                       .                           .
  .               .                       .                           .
  |               |                       |                           |
  |               |                                                   |
  |               |    Create TCP CFW channel towards MS (if needed)  |
  |               |-------------------------------------------------->|
  |               |                                                   |
  |               |<<############## TCP CONNECTION #################>>|
  |               |                                                   |
  |               | CFW SYNC                                          |
  |               |++++++++++++++++++++++++++++++++++++++++++++++++++>|
  |               |                                                   |
  .               .                       .                           .
  .               .                       .                           .

     Figure 12: Consumer Example (IAMM/Media Dialog): Sequence Diagram

   The rest of this section includes a trace of the messages associated
   with the previous sequence diagram.  Only the relevant SIP messages
   are shown (both the INVITEs and the 200 OKs), and only the relevant
   headers are preserved for brevity (Content-Type, From/To, and
   multipart-related information).  Specifically:

   1.  the original INVITE (1.) containing the media-related SDP sent by
       a UAC;

   2.  the INVITE sent by the AS to the MRB (3.), containing both the
       media-related SDP and a Consumer <mediaResourceRequest>;

   3.  the INVITE sent by the MRB (acting as a B2BUA) to the Media
       Server (5.), containing only the media-related SDP from the
       original INVITE;

   4.  the 200 OK sent by the Media Server back to the MRB (7.) to
       complete the media-related negotiation (SDP only);

Top      Up      ToC       Page 78 
   5.  the 200 OK sent by the MRB back to the Application Server in
       response to the original INVITE (9.), containing both the
       media-related information sent by the Media Server and a Consumer
       <mediaResourceRequest> documenting the MRB's decision to use that
       Media Server;

   6.  the 200 OK sent by the Application Server back to the UAC to have
       it set up the RTP channel(s) with the Media Server (11.).


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

Top      Up      ToC       Page 79 
   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="ns56g1x0">
        <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

Top      Up      ToC       Page 80 
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

Top      Up      ToC       Page 81 
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="ns56g1x0">
        <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>

Top      Up      ToC       Page 82 
                    </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

   As the examples illustrate, as in the IAMM/Control Channel example,
   the MRB provides the Application Server with a <media-server-address>
   element in the Consumer response: the 'uri' attribute identifies the

Top      Up      ToC       Page 83 
   specific Media Server to which the MRB has sent the SDP media
   negotiation, and the 'connection-id' enables the Application Server
   to identify to the Media Server the dialog between the MRB and Media
   Server.  This attribute is needed, since according to the framework
   specification [RFC6230] the connection-id is built out of the From/To
   tags of the dialog between the MRB and Media Server; since the MRB
   acts as a B2BUA in this scenario, without that attribute the
   Application Server does not know the relevant tags, thus preventing
   the CFW protocol from working as expected.

   The continuation of the scenario (the Application Server connecting
   to the Media Server to start the Control Channel, the SYNC message,
   etc.) is omitted for brevity.



(page 83 continued on part 5)

Next RFC Part