RFC 7058
Media Control Channel Framework (CFW) Call Flow Examples
Pages: 182
Informational
Informational
Part 6 of 6 – Pages 157 to 182
7.3. Handling Media Dialogs
It is worthwhile to briefly address how media dialogs would be managed whenever an MRB is involved in the following scenarios. In fact, the presence of an MRB may introduce an additional complexity compared to the quite straightforward 1:1 AS-MS topology.7.3.1. Query and Inline-Aware Mode
Normally, especially in the Query and IAMM case, the MRB would only handle Consumer requests by an AS, and after that the AS and the MS picked by the MRB for a specific request would talk directly to each other by means of SIP. This is made possible by the fact that the AS gets the MS SIP URI in reply to its request. In this case, an AS can simply relay media dialogs associated with that session to the right MS to have them handled accordingly. Of course, in order for this to work it is assumed that the AS creates a Control Channel to a chosen MS before it has any requests to service. An example of such a scenario is presented in Figure 52. Please note that this diagram and subsequent diagrams in this section are simplified with respect to the actual protocol interactions. For
instance, the whole SIP transactions are not presented, and only the originating messages are presented in order to clarify the scenario in a simple way. UAC AS MRB MS | | | | | | 1. Consumer request | | | |--------------------------->| | | | | | | | 2. Consumer response | | | |<---------------------------| | | | | | | | 3. COMEDIA negotiation to create CFW channel | | |-------------------------------------------------->| | | | | | |<<############## CFW CONNECTION #################>>| | 4. INVITE xyz | | | |--------------->| | | | | 5. Attach UAC to MS (3PCC) | | |-------------------------------------------------->| | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | . . . . . . . . Figure 52: Handling Media Dialogs in Query/IAMM As can be deduced from the diagram, the interactions among the components are quite straightforward. The AS knows which MS it has been assigned to (as a consequence of the MRB Consumer request, whether it has been achieved by means of HTTP or SIP), and so it can easily attach any UAC accessing its functionality to the MS itself and manipulate its media connections by using the CFW Control Channel as usual. In such a scenario, the MRB is only involved as a locator. Once the MRB provides the AS with the URI of the required resource, it doesn't interfere with subsequent interactions unless it wants to perform monitoring (e.g., by exploiting the Publishing information reported by the MS). As a consequence, the scenario basically becomes 1:1 between the AS and the MS again. Nevertheless, there are cases when having an MRB in the SIP signaling path as well might be a desired feature, e.g., for more control over the use of the resources. Considering how the Consumer interface has been envisaged, this feature is easily achievable, with no change to the protocol required at all. Specifically, in order to achieve such
functionality, the MRB may reply to a Consumer request with a URI for which the MRB is responsible (rather than the MS SIP URI as discussed previously) and map this URI to the actual MS URI in its business logic; this would be transparent to the AS. This way, the AS would interact with the MRB as if it were the MS itself. Figure 53 shows how the scenario would change in this case. UAC AS MRB MS | | | | | | 1. Consumer request | | | |--------------------------->| | | | | | | | 2. Consumer response | | | |<---------------------------| | | | | | | | 3. COMEDIA negotiation | | | |--------------------------->| | | | | 4. COMEDIA neg. | | | |--------------------->| | | | | | |<<############## CFW CONNECTION #################>>| | 5. INVITE xyz | | | |--------------->| | | | | 6. Attach UAC to MS (3PCC) | | | |--------------------------->| | | | | 7. Attach UAC (3PCC) | | | |--------------------->| | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | . . . . . . . . Figure 53: Handling Media Dialogs in Query/IAMM: MRB in the Signaling Path This time, even though the MRB has picked a specific MS after a request from an AS, it replies with another SIP URI, a URI it would reply to itself. The AS would contact that URI in order to negotiate the Control Channel, and the MRB would proxy/forward the request to the actual MS transparently. Eventually, the Control Channel would be instantiated between the AS and the MS. The same happens for UACs handled by the AS; the AS would forward the calls to the URI provided to it, the one handled by the MRB, which would in turn relay the call to the MS in order to have the proper RTP channels created between the UAC and the MS.
This scenario is not very different from the previous scenario, except that the MRB is now on the signaling path for both the SIP control dialog and the SIP media dialogs, allowing it to have more control of the resources (e.g., triggering a BYE if a resource has expired). There are several possible approaches an MRB might take to allocate URIs to map to a requested MS. For example, an MRB might use SIP URI parameters to generate multiple SIP URIs that are unique but that all route to the same host and port, e.g., sip:MrbToMs@mrb.example.com:5080;p=1234567890. Alternatively, the MRB might simply allocate a pool of URIs for which it would be responsible and manage the associations with the requested MS services accordingly.7.3.2. Inline-Unaware Mode
As mentioned previously, in the IUMM case the AS would interact with the MRB as if it were the MS itself. One might argue that this would make the AS act as it would in the IAMM case. This is not the case, however, since the AS actually provided the MRB with information about the resources it required, leading to the selection of a proper MS, while in the IUMM case the MRB would have to pick an MS with no help from the AS at all. That said, the IUMM case is also very interesting with respect to media dialog management. In fact, in the MRB-unaware mode, there would be no Consumer request, and an AS would actually see the MRB as an MS. Unlike the previous scenarios, because there is no AS<->MRB interaction and as such no MS selection process, the MRB would likely be in the signaling path anyway, at least when the AS first shows up. The MRB could either redirect the AS to an MS directly or transparently act as a Proxy/B2BUA and contact an MS (according to implementation-specific policies) on behalf of the unaware AS. While apparently not a problem, this raises an issue when the same unaware AS has several sessions with different MS. The AS would only see one "virtual" MS (the MRB), and so it would relay all calls there, making it hard for the MRB to understand where these media dialogs should belong: specifically, whether the UAC calling belongs to the AS application logic leading to MS1 or MS2, or somewhere else.
One possible, and very simple, approach to take care of this issue is to always relay the SIP dialogs from the same unaware AS to the same MS, as depicted in Figure 54. UAC1 UAC2 AS MRB MS | | | | | | | | 1. COMEDIA negotiation (A) | | | | |--------------------------->| | | | | | 2. COMEDIA neg. (A) | | | | |--------------------->| | | | | | | | |<<############## CFW CONNECTION #################>>| | | | | | | | | 3. COMEDIA negotiation (B) | | | | |--------------------------->| | | | | | 4. COMEDIA neg. (B) | | | | |--------------------->| | | | | | | | |<<############## CFW CONNECTION #################>>| | 5. INVITE xyz | | | |--------------->| | | | | | 6. Attach UAC1 to MS (3PCC)| | | | |--------------------------->| | | | | | 7. Attach UAC (3PCC) | | | | |--------------------->| | | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | | | | 8. INVITE| | | | | jkl | | | | |--------->| | | | | | 9. Attach UAC2 to MS (3PCC)| | | | |--------------------------->| | | | | | 10. Attach UAC (3PCC)| | | | |--------------------->| | | | | | | |<<++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | | . . . . . . . . . . Figure 54: Handling Media Dialogs in IUMM: Always the Same MS In this example, the AS creates two different Control Channel sessions (A and B) to address two different business logic implementations; e.g., the AS SIP URI 'xyz' (associated with CFW session A) may be an IVR pizza-ordering application, while the AS SIP URI 'jkl' (associated with CFW session B) may be associated with a
conference room. It's quite clear, then, that if the MRB forwarded the two CFW sessions to two different MS, the handling of UAC media dialogs would prove troublesome, because the MRB would have difficulty figuring out whether UAC1 should be attached to the MS managing CFW session A or the MS managing CFW session B. In this example, forwarding all CFW sessions and UAC media dialogs coming from the same MRB-unaware AS to the same MS would work as expected. The MRB would in fact leave the mapping of media dialogs and CFW sessions up to the AS. This approach, while very simple and indeed not very scalable, would actually help take care of the issue. In fact, no matter how many separate Control Channels the AS might have with the MRB/MS (in this example, Control Channel A would be mapped to application xyz and Control Channel B to application jkl), the termination point would still always be the same MS, which would consequently be the destination for all media dialogs as well. To overcome the scalability limitations of such an approach, at least in regard to the MRB being in the SIP signaling path for all calls, a different approach needs to be exploited. In fact, especially in the case of different applications handled by the same unaware AS, it makes sense to try to exploit different MS for that purpose and to correctly track media dialogs being forwarded accordingly. This means that the MRB must find a way to somehow redirect the unaware AS to different MS when it predicts or realizes that a different application logic is involved.
To do so, the MRB might use different approaches. One approach would use redirection, e.g., by means of a SIP 302 message in reply to a Control Channel negotiation originated by an unaware AS. Such an approach is depicted in Figure 55. UAC1 AS MRB MS | | | | | | 1. COMEDIA negotiation | | | |--------------------------->| | | | | | | | 2. 302 Moved (MS) | | | |<---------------------------| | | | | | | | 3. COMEDIA negotiation | | | |-------------------------------------------------->| | | | | | |<<############## CFW CONNECTION #################>>| | | | | | 4. INVITE xyz | | | |--------------->| | | | | 5. Attach UAC1 to MS (3PCC)| | | |-------------------------------------------------->| | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | . . . . . . . . Figure 55: Handling Media Dialogs in IUMM: Redirection With this approach, the MRB might redirect the AS to a specific MS whenever a new Control Channel is to be created, and as a consequence the AS would redirect the related calls there. This is similar to the first approach of the Query/IAMM case, with the difference that no Consumer request would be involved. The scenario would again fall back to a 1:1 topology between the AS and the MS, making the interactions quite simple. Just as before, the MRB might be interested in being in the signaling path for the SIP dialogs, instead of just acting as a locator. A third potential approach could be implementing the "virtual" URIs handled by the MRB, as described in the previous section. Rather than resorting to explicit redirection or always using the same MS,
the MRB may redirect new SIP control dialogs to one of its own URIs, using the same approach previously presented in Figure 53. Such an approach, as applied to the IUMM case, is depicted in Figure 56. UAC1 AS MRB MS | | | | | | 1. COMEDIA negotiation (MRB) | | | |------------------------------>| | | | | | | | 2. 302 Moved (MRB') | | | |<------------------------------| | | | | | | | 3. COMEDIA negotiation (MRB') | | | |------------------------------>| | | | | 4. COMEDIA neg. | | | |------------------> | | | | | |<<############## CFW CONNECTION #################>>| | | | | | 5. INVITE xyz | | | |--------------->| | | | | 6. Attach UAC1 to MRB' (3PCC) | | | |------------------------------>| | | | | 7 Attach UAC (3PCC) | | |------------------> | | | | |<<++++++++++++++++++++++ RTP channels ++++++++++++++++++++++++++++>>| | | | | . . . . . . . . Figure 56: Handling Media Dialogs in IUMM: MRB in the Signaling Path It is worth pointing out, though, that in both cases there are scenarios where there could be no assurance that the 302 sent by the MRB would be seen by the AS. In fact, should a proxy be between the AS and the MRB, such a proxy could itself act on the 302. To properly cope with such an issue, the MRB might also use the 'Contact' header in the SIP responses to the INVITE to address the right MS. Although the AS is not required to use the information in such a header to reach the MS, it could be reasonable to exploit it for that purpose, as it would take care of the proxy scenario mentioned above.
To conclude, there is a further approach an MRB might try to exploit to take care of the IUMM case. Since, as explained before, the issues related to the IUMM case mostly relate to the fact that the MRB is seen as a single MS instance by the AS, a simple way to overcome this might be to make the MRB look like a set of different MS right away; this can be done by simply provisioning the unaware AS with a series of different URIs, all handled by the MRB itself acting as a pool of "virtual" MS. This way, the AS may be designed to use different MS for different classes of calls, e.g., for different applications it is managing (two in the example presented in this section), and as such would contact two different provisioned URIs to create two distinct Control Channels towards two different MS. Since both of the URIs would be handled by the MRB, the MRB can use them to determine to which MS each call should be directed. Expanding on Figure 54 by removing the constraint to always use the same MS, this new scenario might look like that depicted in Figure 57.
UAC1 UAC2 AS MRB MS1 MS2 | | | | | | | | | 1. COMEDIA negotiation (A) | | | | | | INVITE fake-ms1 | | | | | |--------------------------->| | | | | | | 2. COMEDIA (A) | | | | | |---------------->| | | | | | | | | | |<<############## CFW CONNECTION 1 ##########>>| | | | | | | | | | | 3. COMEDIA negotiation (B) | | | | | | INVITE fake-ms2 | | | | | |--------------------------->| | | | | | | 4. COMEDIA neg. (B) | | | | |--------------------->| | | | | | | | | |<<############## CFW CONNECTION 2 ###############>>| | | | | | | | 5. INVITE xyz | | | | |--------------->| | | | | | | 6. Attach UAC1 to fake-ms1 (3PCC) | | | | |--------------------------->| | | | | | | 7. Attach UAC | | | | | |---------------->| | | | | | | | |<<++++++++++++++++++++++ RTP channels +++++++++++++++++++++++>>| | | | | | | | | 8. INVITE jkl | | | | |--------------->| | | | | | | 9. Attach UAC2 to fake-ms2 (3PCC) | | | | |--------------------------->| | | | | | | 10. Attach UAC | | | | | |--------------------->| | | | | | | |<<+++++++++++++++++++++++++ RTP channels +++++++++++++++++++++++++>>| | | | | | | . . . . . . . . . . . . Figure 57: Handling Media Dialogs in IUMM: Provisioned URIs In this new example, we still assume that the same unaware AS is handling two different applications, still associated with the same URIs as before. This time, though, we also assume that the AS has been designed to try to use different MS instances to handle the two very different applications for which it is responsible. We also assume that it has been configured to be able to use two different MS instances, reachable at SIP URI 'fake-ms1' and 'fake-ms2',
respectively, and both actually handled by the MRB transparently. This results, just as before, in two different Control Channels (A and B) being created, but this time towards two different MS. Specifically, the MRB makes sure that for this AS the Control Channel negotiation towards 'fake-ms1' is actually redirected to MS1. At the same time, 'fake-ms2' is associated with MS2. Once the AS has set up the Control Channels with both of the MS, it is ready to handle media dialogs. UAC1 calls the SIP URI 'xyz' on the AS to order a pizza. The AS attaches the media dialog to the MS it knows is responsible for that branch of application logic, i.e., 'fake-ms1'. The MRB in turn makes sure that it reaches the right MS instance, MS1. Later on, a different user, UAC2, calls SIP URI 'jkl' to join a conference room. This time, the AS attaches this new media dialog to the MS instance handling the conference application, i.e., 'fake-ms2'. Again, the MRB makes sure that it is actually MS2 that receives the dialog. Again, this diagram is only meant to describe how the MRB might enforce its decisions. Just as described in the previous examples, the MRB may choose to either act as a Proxy/B2BUA between the AS and the MS instances or redirect the AS to the right MS instances when they're first contacted (e.g., by means of the Contact header and/or a SIP redirect, as explained before) and let the AS attach the media dialogs by itself.7.3.3. CFW Protocol Behavior
As shown in the previous diagrams, no matter what the topology, the AS and MS usually end up with a direct connection with respect to the CFW Control Channel. As such, it can be expected that the CFW protocol continue to work as it should, and as a consequence all the call flows presented in this document can easily be reproduced in those circumstances as well. Nevertheless, one aspect needs to be considered very carefully. It's worthwhile to remind readers that both the AS and the MS use some SIP-related information to address the entities they manipulate. This is the case, for instance, for the <connectionid> element to which both the AS and the MS refer when addressing a specific UAC. As explained in Section 6, this 'connectionid' identifier is constructed by concatenating the 'From' and 'To' tags extracted from a SIP header: specifically, from the headers of the AS<->MS leg that allows a UAC to be attached to the MS. The presence of an additional component in the path between the AS and the MS, the MRB, might alter these tags, thus causing the AS to use tags (AS<->MRB) different than those used by the MS (MRB<->MS). This would result in the AS and MS using different 'connectionid' identifiers to address the same UAC, thus preventing the protocol from working as expected. As a
consequence, it's very important that any MRB implementation take very good care to preserve the integrity of the involved SIP headers when proxying/forwarding SIP dialogs between the AS and MS, in order not to "break" the behavior of the protocol. Let's take, for instance, the scenario depicted in Figure 53, especially steps 6 and 7, which specifically address a UAC being attached by an AS to an MS via the MRB. Let's assume that Figure 58 shows what happens to the 'From' and 'To' headers in that scenario, when dealing with the 3PCC approach to attach a specific UAC to the MS. UAC AS MRB MS | | | | | INVITE xyz | | | |--------------->| | | | | SIP [..] | | | | From: <..>;tag=a1b2c3 | | | | To: <..>;tag=d4e5f6 | | | |<------------------------>| | | | | SIP [..] | | | | From: <..>;tag=aaabbb | | | | To: <..>;tag=cccddd | | | |<---------------------->| | | | | | | 1. CONTROL (play announcement to UAC) | | |-------------------------------------------------->| | | 2. 200 (IVR Error!) | | |<--------------------------------------------------| | | | | . . . . . . . . Figure 58: CFW Protocol Behavior in the Case of Manipulated Tags In this example, once done with the 3PCC, and now that the UAC is attached to the MS, the AS and the MS end up with different interpretations of what the 'connectionid' for the UAC should be. In fact, the AS builds a 'connectionid' using the tags it is aware of (a1b2c3:d4e5f6), while the MS builds a different identifier after receiving different information from the MRB (aaabbb:cccddd). As a consequence, when the AS tries to play an announcement to the UAC using the connectionid it correctly constructed, the MS just as correctly replies with an error, since it doesn't know that identifier. This is correct protocol behavior, because in this case it was caused by misuse of the information needed for it to work as expected.
1. AS -> MS (CFW CONTROL, play)
-------------------------------
CFW ffhg45dzf123 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 284
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogstart connectionid="a1b2c3:d4e5f6">
<dialog>
<prompt>
<media loc="http://www.example.net/hello.wav"/>
</prompt>
</dialog>
</dialogstart>
</mscivr>
2. AS <- MS (CFW 200 OK)
------------------------
CFW ffhg45dzf123 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 148
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<response status="407" reason="connectionid does not exist"
dialogid=""/>
</mscivr>
In an even worse scenario, the connectionid might actually exist but
might be mapped to a different UAC. In such a case, the transaction
would succeed, but a completely different UAC would be involved, thus
causing a silent failure that neither the AS nor the MS would be
aware of.
That said, proper management of these sensitive pieces of information
by the MRB would prevent such failure scenarios from happening. How
this issue is taken care of in the IAMM case (both CFW-based and
media dialog-based) has already been described. Addressing this
issue for the IUMM case is not documented in [RFC6917] as explicitly
out of scope and as such may be implementation specific.
The same applies to SDP fields as well. In fact, the AS and MS use
ad hoc SDP attributes to instantiate a Control Channel, as they use
SDP labels to address specific media connections of a UAC media
dialog when a fine-grained approach is needed. As a consequence, any
MRB implementation should limit any SDP manipulation as much as possible or at least take very good care not to cause changes that could "break" the expected behavior of the CFW protocol.8. Security Considerations
All the MEDIACTRL documents have strong statements regarding security considerations within the context of the interactions occurring at all levels among the involved parties. Considering the sensitive nature of the interaction between AS and MS, particular efforts have been devoted to providing guidance on how to secure what flows through a Control Channel. In fact, transactions concerning dialogs, connections, and mixes are quite strongly related to resources actually being deployed and used in the MS. This means that it is in the interest of both AS and MS that resources created and handled by an entity are not manipulated by a potentially malicious third party if permission was not granted. Because strong statements are provided in the aforementioned documents and these documents provide good guidance to implementors with respect to these issues, this section will only provide the reader with some MEDIACTRL call flows that show how a single secured MS is assumed to reply to different AS when receiving requests that may cross the bounds within which each AS is constrained. This would be the case, for instance, for generic auditing requests, or explicit conference manipulation requests where the involved identifiers are not part of the context of the originating AS. To address a very specific scenario, let's assume that two different AS, AS1 and AS2, have established a Control Channel with the same MS. Considering the SYNC transaction that an AS and an MS use to set up a Control Channel, the MS is able to discern the requests coming from AS1 from the requests coming from AS2. In fact, as explained in Sections 5.1 and 5.2, an AS and an MS negotiate a cfw-id attribute in the SDP, and the same value is subsequently used in the SYNC message on the Control Channel that is created after the negotiation, thus reassuring both the AS and the MS that the Control Channel they share is in fact the channel they negotiated in the first place.
Let's also assume that AS1 has created a conference mix
(confid=74b6d62) to which it has attached some participants within
the context of its business logic, while AS2 has created a currently
active IVR dialog (dialogid=dfg3252) with a user agent it is handling
(237430727:a338e95f). AS2 has also joined two connections to each
other (1:75d4dd0d and 1:b9e6a659). Clearly, it is highly desirable
that AS1 not be aware of what AS2 is doing with the MS and vice
versa, and that they not be allowed to manipulate each other's
resources. The following transactions will occur:
1. AS1 places a generic audit request to both the Mixer and IVR
packages.
2. AS2 places a generic audit request to both the Mixer and IVR
packages.
3. AS1 tries to terminate the dialog created by AS2 (6791fee).
4. AS2 tries to join a user agent it handles (1:272e9c05) to the
conference mix created by AS1 (74b6d62).
A sequence diagram of the above-mentioned transactions is depicted in Figure 59, which shows how the MS is assumed to reply in all cases, in order to avoid security issues: AS1 AS2 MS | | | | A1. CONTROL (IVR audit) | |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| | | A2. 200 OK | |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| | | | | B1. CONTROL (Mixer audit) | |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| | | B2. 200 OK | |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| | | | | | C1. CONTROL (IVR audit) | | |++++++++++++++++++++++++++++++++>>| | | C2. 200 OK | | |<<++++++++++++++++++++++++++++++++| | | | | | D1. CONTROL (Mixer audit) | | |++++++++++++++++++++++++++++++++>>| | | D2. 200 OK | | |<<++++++++++++++++++++++++++++++++| | | | | E1. CONTROL (dialogterminate) | |++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>| | | E2. 403 Forbidden | |<<++++++++++++++++++++++++++++++++++++++++++++++++++++++++| | | | | | F1. CONTROL (join UAC&conf[AS1]) | | |++++++++++++++++++++++++++++++++>>| | | F2. 403 Forbidden | | |<<++++++++++++++++++++++++++++++++| | | | . . . . . . Figure 59: Security Considerations: Framework Transaction
The expected outcome of the transaction is that the MS partially
"lies" to both AS1 and AS2 when replying to the audit requests (not
all of the identifiers are reported, but only those identifiers with
which each AS is directly involved), and the MS denies the requests
for the unauthorized operations (403). Looking at each transaction
separately:
o In the first transaction (A1), AS1 places a generic <audit>
request to the IVR package. The request is generic, since no
attributes are passed as part of the request, meaning that AS1 is
interested in the MS capabilities as well as all of the dialogs
that the MS is currently handling. As can be seen in the reply
(A2), the MS only reports in the <auditresponse> the package
capabilities, while the <dialogs> element is empty; this is
because the only dialog the MS is handling has actually been
created by AS2, which causes the MS not to report the related
identifier (6791fee) to AS1. In fact, AS1 could use that
identifier to manipulate the dialog, e.g., by tearing it down and
thus causing the service to be interrupted without AS2's
intervention.
o In the second transaction (B1), AS1 places an identical <audit>
request to the Mixer package. The request is again generic,
meaning that AS1 is interested in the package capabilities as well
as all the mixers and connections that the package is handling at
the moment. This time, the MS reports not only capabilities (B2)
but information about mixers and connections as well. However,
this information is not complete; in fact, only information about
mixers and connections originated by AS1 is reported (mixer
74b6d62 and its participants), while the information originated by
AS2 is omitted in the report. The motivation is the same as
before.
o In the third and fourth transactions (C1 and D1), it's AS2 that
places an <audit> request to both the IVR and Mixer packages. As
with the previous transactions, the audit requests are generic.
Looking at the replies (C2 and D2), it's obvious that the
capabilities section is identical to the replies given to AS1. In
fact, the MS has no reason to "lie" about what it can do. The
<dialogs> and <mixers> sections are totally different. AS2 in
fact receives information about its own IVR dialog (6791fee),
which was omitted in the reply to AS1, while it only receives
information about the only connection it created (1:75d4dd0d and
1:b9e6a659) without any details related to the mixers and
connections originated by AS1.
o In the fifth transaction (E1), AS1, instead of just auditing the
packages, tries to terminate (<dialogterminate>) the dialog
created by AS2 (6791fee). Since the identifier has not been
reported by the MS in the reply to the previous audit request, we
assume that AS1 accessed it via a different out-of-band mechanism.
This is assumed to be an unauthorized operation, because the
above-mentioned dialog is outside the bounds of AS1; therefore,
the MS, instead of handling the syntactically correct request,
replies (E2) with a framework-level 403 message (Forbidden),
leaving the dialog untouched.
o Similarly, in the sixth and last transaction (F1), AS2 tries to
attach (<join>) one of the UACs it is handling to the conference
mix created by AS1 (74b6d62). Just as in the previous
transaction, the identifier is assumed to have been accessed by
AS2 via some out-of-band mechanism, since the MS didn't report it
in the reply to the previous audit request. While one of the
identifiers (the UAC) is actually handled by AS2, the other (the
conference mix) is not; therefore, as with the fifth transaction,
this last transaction is regarded by the MS as outside the bounds
of AS2. For the same reason as before, the MS replies (F2) with a
framework-level 403 message (Forbidden), leaving the mix and the
UAC unjoined.
A1. AS1 -> MS (CFW CONTROL, audit IVR)
--------------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 81
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<audit/>
</mscivr>
A2. AS1 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 140e0f763352 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 1419
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<auditresponse status="200">
<capabilities>
<dialoglanguages/>
<grammartypes/>
<recordtypes>
<mimetype>audio/x-wav</mimetype>
<mimetype>video/mpeg</mimetype>
</recordtypes>
<prompttypes>
<mimetype>audio/x-wav</mimetype>
<mimetype>video/mpeg</mimetype>
</prompttypes>
<variables>
<variabletype type="date"
desc="value formatted as YYYY-MM-DD">
<format desc="month day year">mdy</format>
<format desc="year month day">ymd</format>
<format desc="day month year">dmy</format>
<format desc="day month">dm</format>
</variabletype>
<variabletype type="time" desc="value formatted as HH:MM">
<format desc="24 hour format">t24</format>
<format desc="12 hour format with am/pm">t12</format>
</variabletype>
<variabletype type="digits" desc="value formatted as D+">
<format desc="general digit string">gen</format>
<format desc="cardinal">crn</format>
<format desc="ordinal">ord</format>
</variabletype>
</variables>
<maxpreparedduration>60s</maxpreparedduration>
<maxrecordduration>1800s</maxrecordduration>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<dialogs>
</dialogs>
</auditresponse>
</mscivr>
B1. AS1 -> MS (CFW CONTROL, audit mixer)
----------------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 87
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<audit/>
</mscmixer>
B2. AS1 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 903
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<auditresponse status="200">
<capabilities>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<mixers>
<conferenceaudit conferenceid="74b6d62">
<participants>
<participant id="1864574426:e2192766"/>
<participant id="1:5a97fd79"/>
</participants>
<video-layout min-participants="1">
<quad-view/>
</video-layout>
</conferenceaudit>
<joinaudit id1="1864574426:e2192766" id2="74b6d62"/>
<joinaudit id1="1:5a97fd79" id2="74b6d62"/>
</mixers>
</auditresponse>
</mscmixer>
C1. AS2 -> MS (CFW CONTROL, audit IVR)
--------------------------------------
CFW 0216231b1f16 CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 81
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<audit/>
</mscivr>
C2. AS2 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 0216231b1f16 200
Timeout: 10
Content-Type: application/msc-ivr+xml
Content-Length: 1502
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<auditresponse status="200">
<capabilities>
<dialoglanguages/>
<grammartypes/>
<recordtypes>
<mimetype>audio/wav</mimetype>
<mimetype>video/mpeg</mimetype>
</recordtypes>
<prompttypes>
<mimetype>audio/wav</mimetype>
<mimetype>video/mpeg</mimetype>
</prompttypes>
<variables>
<variabletype type="date"
desc="value formatted as YYYY-MM-DD">
<format desc="month day year">mdy</format>
<format desc="year month day">ymd</format>
<format desc="day month year">dmy</format>
<format desc="day month">dm</format>
</variabletype>
<variabletype type="time" desc="value formatted as HH:MM">
<format desc="24 hour format">t24</format>
<format desc="12 hour format with am/pm">t12</format>
</variabletype>
<variabletype type="digits" desc="value formatted as D+">
<format desc="general digit string">gen</format>
<format desc="cardinal">crn</format>
<format desc="ordinal">ord</format>
</variabletype>
</variables>
<maxpreparedduration>60s</maxpreparedduration>
<maxrecordduration>1800s</maxrecordduration>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<dialogs>
<dialogaudit dialogid="6791fee" state="started"
connectionid="237430727:a338e95f"/>
</dialogs>
</auditresponse>
</mscivr>
D1. AS2 -> MS (CFW CONTROL, audit mixer)
----------------------------------------
CFW 515f007c5bd0 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 87
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<audit/>
</mscmixer>
D2. AS2 <- MS (CFW 200, auditresponse)
--------------------------------------
CFW 515f007c5bd0 200
Timeout: 10
Content-Type: application/msc-mixer+xml
Content-Length: 548
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<auditresponse status="200">
<capabilities>
<codecs>
<codec name="audio"><subtype>basic</subtype></codec>
<codec name="audio"><subtype>gsm</subtype></codec>
<codec name="video"><subtype>h261</subtype></codec>
<codec name="video"><subtype>h263</subtype></codec>
<codec name="video"><subtype>h263-1998</subtype></codec>
<codec name="video"><subtype>h264</subtype></codec>
</codecs>
</capabilities>
<mixers>
<joinaudit id1="1:75d4dd0d" id2="1:b9e6a659"/>
</mixers>
</auditresponse>
</mscmixer>
E1. AS1 -> MS (CFW CONTROL, dialogterminate)
--------------------------------------------
CFW 7fdcc2331bef CONTROL
Control-Package: msc-ivr/1.0
Content-Type: application/msc-ivr+xml
Content-Length: 127
<mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
<dialogterminate dialogid="6791fee" immediate="true"/>
</mscivr>
E2. AS1 <- MS (CFW 403 Forbidden)
---------------------------------
CFW 7fdcc2331bef 403
F1. AS2 -> MS (CFW CONTROL, join to conference)
-----------------------------------------------
CFW 140e0f763352 CONTROL
Control-Package: msc-mixer/1.0
Content-Type: application/msc-mixer+xml
Content-Length: 117
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1:272e9c05" id2="74b6d62"/>
</mscmixer>
F2. AS2 <- MS (CFW 403 Forbidden)
---------------------------------
CFW 140e0f763352 403
9. Acknowledgments
The authors would like to thank Dale Worley for the thorough review
of the whole document and for contributing text to make the document
easier to read.
10. References
10.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", RFC 6230, May 2011. [RFC6231] McGlashan, S., Melanchuk, T., and C. Boulton, "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", RFC 6231, May 2011. [RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer Control Package for the Media Control Channel Framework", RFC 6505, March 2012. [RFC6917] Boulton, C., Miniero, L., and G. Munson, "Media Resource Brokering", RFC 6917, April 2013. [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008. [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.10.2. Informative References
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar Specification Version 1.0", W3C Recommendation, March 2004. [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006. [RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.
Authors' Addresses
Alessandro Amirante University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: alessandro.amirante@unina.it Tobia Castaldi Meetecho Via Carlo Poerio 89 Napoli 80100 Italy EMail: tcastaldi@meetecho.com Lorenzo Miniero Meetecho Via Carlo Poerio 89 Napoli 80100 Italy EMail: lorenzo@meetecho.com Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: spromano@unina.it