RFC 6917
Media Resource Brokering
Pages: 136
Proposed Standard
Proposed Standard
Part 4 of 6 – Pages 58 to 83
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]).
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).
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"/>
<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: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.
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').
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>
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.
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.
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) | |
|-------------------------------------------------->| |
| | |
|<<############## 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.
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>
</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
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">
<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.).
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.
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 | | |
|-------------->| | |
| | | | |<<*************************** 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);
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
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
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="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>
</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
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)