| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 12, 2008.
This document provides with a list of more or less detailed Media Control Channel Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) call flows. It aims at being a simple guide throughout the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a hopefully helpful base reference documentation for both implementors and protocol researchers.
1.
Introduction
2.
Conventions
3.
Terminology
4.
Overview
4.1.
A Practical Approach
4.1.1.
State Diagrams
4.1.2.
Implementation
5.
Control Channel Establishment
5.1.
COMEDIA Negotiation
5.2.
SYNCH
6.
Use-case scenarios and examples
6.1.
Echo Test
6.1.1.
Direct Echo Test
6.1.2.
Echo Test based on Recording
6.2.
Phone Call
6.2.1.
Direct Connection
6.2.2.
Conference-based Approach
6.3.
Voice Mail
6.4.
Conferencing
6.4.1.
Simple Bridging
6.4.2.
Rich Conference Scenario
6.4.3.
Conferencing with Floor Control
6.4.4.
Coaching Scenario
6.4.5.
Sidebars
7.
Security Considerations
8.
Change Summary
9.
Acknowledgements
10.
References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
TBD. Discussion upon SIP/MEDIACTRL and separation of responsibilities between Application Servers (application logic) and Media Servers (media management and manipulation).
Requirements -> Architecture -> Framework (Control Packages)
| TOC |
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) and indicate requirement levels for compliant implementations.
Besides, note that due to RFC formatting conventions, this document often splits SIP/SDP and SCFW 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.
| TOC |
This document pretty much makes use of the same terminology as the one that can be found in the referenced documents. The following terms are only a summarization of the most commonly used ones in this context, mostly derived from the terminology used in the related documents:
- Application Server:
- an entity that requests media processing and manipulation from a Media Server; typical examples are Back to Back User Agents (B2BUA) and endpoints requesting manipulation of a third-party's media stream.
- Media Server:
- an entity that performs a service, such as media processing, on behalf of an Application Server; typical provided functionality are mixing, announcement, tone detection and generation, and play and record services.
- Control Channel:
- a reliable connection between an Application Server and a Media Server that is used to exchange Framework messages.
| TOC |
This document provides with a list of more or less detailed MEDIACTRL Media Control Channel Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) call flows. The motivation for this comes from our implementation experience with the framework and its protocol. This drove us to writing what could be both a simple guide throughout the use of the several interfaces between Application Servers and MEDIACTRL-based Media Servers (and the related correlations between them) and a hopefully helpful base reference documentation for other implementors and protocol researchers.
Following this spirit, this document covers several aspects of the interaction between Application Servers and Media Servers. However, in the context of this document, the call flows almost always depict the interaction between a single Application Server (which, for the sake of conciseness, is called AS from now on) and a single Media Server (MS). To ease up the understanding of all the flows (for what concerns both SIP dialogs and SCFW transactions), the domains hosting the AS and the MS in all the scenarios are called, respectively, as.com and ms.org.
In the next paragraphs a small overview of our implementation approaches and choices is described, with particular focus upon the protocol-related aspects. This involves state diagrams for what concerns both the client side (the AS) and the server side (the MS). Of course, this section is not at all to be considered a mandatory approach to the implementation of the framework. It is only meant to ease up the understanding of how the framework works from a practical point of view, and of the following examples.
Once done with this preliminary considerations, in the subsequent sections real-life scenarios are faced. In this context, first of all, the establishment of the Control Channel is dealt with: after that, some typical use case scenarios, involving the most typical multimedia applications, are depicted and described.
| TOC |
TBD.
| TOC |
TBD. (talk about both diagrams; update both diagrams reflecting the use of the new MS-generated CONTROL event for notifications)
+------------------+ CONTROL/- +------------------+ API 202/202
| Idle/'terminate' |------------>| CONTROL received |------------+
+------------------+ +------------------+ |
^ ^ ^ API 200/200 | | |
| | | | | v
| | +------------------+ | +-----------------+
| 200/- | API Error/Error | | CONTROL pending |
| +----------------------------+ +-----------------+
| |
| |
| API pending/ |
+-------------+ REPORT pending |
| Waiting for | v
| last 200 |<------------------------+ +----------------+
+-------------+ | | 'pending' sent |
^ | +----------------+
| | |
| | |
| API terminate/ | API terminate/ |
| REPORT terminate | REPORT termnate | 200/-
| | v
+--------------------+ | +---------------------+
| 'update' confirmed |------+ +--------| 'pending' confirmed |
+--------------------+ | +---------------------+
^ | API update/ |
| | REPORT update |
| v |
| 200/- +---------------+ | API update/
+--------------| 'update' sent |<----------+ REPORT update
+---------------+
| Figure 1: Media Server SCFW State Diagram |
+--------------+ 202/- +--------------+
+-->| CONTROL sent |---------->| 202 received |
| +--------------+ +--------------+
| | | |
| | | |
API CONTROL/ | | 200/- | | REPORT 'pending'/
send CONTROL | | | v send 200
| | | Error/ +-----------+
+------------------+ | | Error | 'pending' |
| Idle/'terminate' |<-+ | +-----------+
+------------------+<---------+ | |
^ ^ | |
| | REPORT 'terminate'/ | |
| | send 200 | |
| +--------------------------------+ | REPORT 'update'/
| | send 200
| REPORT 'terminate'/ |
| send 200 |
| +-----------+ |
+---------------------| 'update ' |<--------------+
+-----------+
^ |
| | REPORT 'update'/
+------+ send 200
| Figure 2: Application Server SCFW State Diagram |
| TOC |
TBD. (media- and macro-connections, conferences, plugins)
| TOC |
As specified in [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.), the preliminary step to any interaction between an AS and a MS is the establishment of a control channel between the two. As explained in the next subsection, this is accomplished by means of a so-called COMEDIA [RFC4145] (Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.) negotiation. This negotiation allows for a TCP connection to be created between the AS and the MS: once they have connected, a SYNCH message sent by the AS to the MS consolidates the control channel.
AS MS
| |
| INVITE (COMEDIA) |
|------------------------------>|
| 100 (Trying) |
|<------------------------------|
| 200 OK (COMEDIA) |
|<------------------------------|
| ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
| SYNCH (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNCH
| |<-+
| 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
| Figure 3: Control Channel Establishment |
| TOC |
As a first step, the AS and the MS establish a Control SIP dialog. This is usually originated by the AS itself. The AS generates a SIP INVITE message containing in its SDP body information about the TCP connection it wants to establish with the MS. In the provided example (see Figure 4 (COMEDIA Negotiation: Sequence Diagram) and the attached call flow), the AS wants to actively open a new TCP connection, which on his side will be bound to port 5757. If the request is fine, the MS answers with its own offer, by communicating to the AS the transport address to connect to in order to establish the TCP connection. In the provided example, the MS will listen on the port 7575. Once this negotiation is over, the AS can effectively connect to the MS.
Note that the provided example also includes the indication, from both the AS and the MS, of the supported control packages. This is achieved by means of a series of 'ctrl-package' attributes as specified in [I‑D.boulton‑mmusic‑sdp‑control‑package‑attribute] (Boulton, C., “A Session Description Protocol (SDP) Control Package Attribute,” March 2009.). In the example, the AS supports (or is only interested to) two packages: the Basic IVR and the Audio Conferencing. The MS replies with the list of packages it supports, by adding the VoiceXML IVR package to the list provided by the AS. It is worth noting that this exchange of information is not meant as a strictly containing negotiation of packages: in case the AS gets to know that one or more packages it needs are not supported according to the indications sent by the MS, it MAY choose not to open a control channel with the MS at all, if its application logic leads to such a decision. The actual negotiation of control packages is done subsequenty through the use of the framework SYNCH transaction.
AS MS
| |
| 1. INVITE (COMEDIA) |
|------------------------------>|
| 2. 100 (Trying) |
|<------------------------------|
| 3. 200 OK (COMEDIA) |
|<------------------------------|
| 4. ACK |
|------------------------------>|
| |
|==============================>|
| TCP CONNECT (CTRL CHANNEL) |
|==============================>|
| |
. .
. .
| Figure 4: COMEDIA Negotiation: Sequence Diagram |
1. AS -> MS (SIP INVITE) ------------------------ INVITE sip:MediaServer@ms.org:5060 SIP/2.0 Via: SIP/2.0/UDP as.com:5060;branch=z9hG4bK-3724-1-0 From: ApplicationServer \ <sip:ApplicationServer@as.com:5060>;tag=3724Pp001 To: MediaServer <sip:MediaServer@ms.org:5060> Call-ID: 1-3724@as.com Cseq: 1 INVITE Contact: sip:ApplicationServer@as.com:5060 Max-Forwards: 70 Content-Type: application/sdp Content-Length: 227 v=0 o=- 53655765 2353687637 IN IP4 as.com s=- c=IN IP4 as.com t=0 0 m=application 5757 TCP/SCFW a=setup:active a=connection:new a=ctrl-package:msc-ivr-basic/1.0 a=ctrl-package:msc-conf-audio/1.0 2. AS <- MS (SIP 100 Trying) ---------------------------- SIP/2.0 100 Trying Via: SIP/2.0/UDP as.com:5060;branch=z9hG4bK-3724-1-0 To: "MediaServer"<sip:MediaServer@ms.org:5060>;tag=07fa6e5b From: "ApplicationServer" \ <sip:ApplicationServer@as.com:5060>;tag=3724Pp001 Call-ID: 1-3724@as.com CSeq: 1 INVITE Content-Length: 0 3. AS <- MS (SIP 200 OK) ------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP as.com:5060;branch=z9hG4bK-3724-1-0 Contact: <sip:MediaServer@ms.org:5060> To: "MediaServer"<sip:MediaServer@ms.org:5060>;tag=07fa6e5b From: "ApplicationServer" \ <sip:ApplicationServer@as.com:5060>;tag=3724Pp001 Call-ID: 1-3724@as.com CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INVITE Content-Type: application/sdp Content-Length: 267 v=0 o=- 53655765 2353687638 IN IP4 ms.org s=MediaCtrl c=IN IP4 ms.org t=0 0 m=application 7575 TCP/SCFW * a=connection:new a=setup:passive a=ctrl-package:msc-ivr-basic/1.0 a=ctrl-package:msc-conf-audio/1.0 a=ctrl-package:msc-ivr-vxml/1.0 4. AS -> MS (SIP ACK) --------------------- ACK sip:MediaServer@ms.org:5060 SIP/2.0 Via: SIP/2.0/UDP as.com:5060;branch=z9hG4bK-3724-1-6 From: ApplicationServer \ <sip:ApplicationServer@as.com:5060>;tag=3724Pp001 To: MediaServer <sip:MediaServer@ms.org:5060>;tag=07fa6e5b Call-ID: 1-3724@as.com Cseq: 1 ACK Contact: sip:ApplicationServer@as.com:5060 Max-Forwards: 70 Content-Length: 0
| TOC |
Once the AS and the MS have successfully established a TCP connection, an additional step is needed before the control channel can be used. In fact, as seen in the previous subsection, the first interaction between the AS and the MS happens by means of a SIP dialog, which in turns allows for the creation of the TCP connection. This introduces the need for a proper correlation between the above mentioned SIP dialog and TCP connection, so that the MS can be sure the connection came from the AS which requested it. This is accomplished by means of a dedicated framework message called SYNCH. This SYNCH message makes use of a properly constructed Dialog-ID (a composition of the Call-ID and the From and To tags extracted by the SIP dialog) to validate the control channel. Besides, it offers an additional negotiation mechanism. In fact, the AS uses the SYNCH not only to properly correlate as explained before, but also to negotiate with the MS the control packages it is interested to, as well as to agree on a Keep-Alive timer needed by both the AS and the MS to understand if problems on the connection occur. In the provided example (see Figure 4 (COMEDIA Negotiation: Sequence Diagram) and the related call flow), the AS sends a SYNCH with a Dialog-ID constructed as needed (check the Call-ID and the two tags from the SIP dialog) and requests access to two control packages, specifically the Basic IVR and the Audio Conferencing package (These are the same packages the AS previously indicated in its SDP as specified in [I‑D.boulton‑mmusic‑sdp‑control‑package‑attribute] (Boulton, C., “A Session Description Protocol (SDP) Control Package Attribute,” March 2009.), with the difference that this time they are reported in the context of a binding negotiation). Besides, it instructs the MS that a 100 seconds timeout is to be used for Keep-Alive. The MS validates the request by matching the received Dialog-ID with the SIP dialog values and, assuming it supports the control packages the AS requested access to (and for the sake of this document we assume it does), it answers with a 200 message. Additionally, the MS provides the AS with a list of other unrequested packages it supports (in this case the VoiceXML IVR package).
AS MS
. .
. .
| |
| 1. SYNCH (Dialog-ID, etc.) |
|+++++++++++++++++++++++++++++>>|
| |--+
| | | Check SYNCH
| |<-+
| 2. 200 OK |
|<<+++++++++++++++++++++++++++++|
| |
. .
. .
| Figure 5: SYNCH: Sequence Diagram |
1. AS -> MS (SCFW SYNCH) ------------------------ SCFW 6b8b4567327b SYNCH Dialog-ID: 3724Pp001~1-3724@as.com~07fa6e5b K-alive: 100 Packages: msc-ivr-basic/1.0,msc-conf-audio/1.0 2. AS <- MS (SCFW 200) ---------------------- SCFW 6b8b4567327b 200 K-alive: 100 Packages: msc-ivr-basic/1.0,msc-conf-audio/1.0 Supported: msc-ivr-vxml/1.0
At this step, the control channel is finally established, and can be used by the AS to request services from the MS.
| TOC |
The following scenarios have been chosen for their common presence in many rich real-time multimedia applications. Each scenario is depicted as a set of call flows, involving both the SIP/SDP signaling (UACs<->AS<->MS) and the Control Channel communication (AS<->MS).
All the examples assume that a Control Channel has already been correctly established and SYNCHed between the reference AS and MS. Besides, unless stated otherwise, the same UAC session is referenced in all the above mentioned examples. The UAC session is considered to have been created as the Figure 6 (3PCC Sequence Diagram) describes:
UAC AS MS | | | | INVITE (X) | | |------------------>| | | 180 (Ringing) | | |<------------------| | | |--+ | | | | Handle app(X) | | |<-+ | | | INVITE (X) as 3PCC | | |-------------------------->| | | 100 (Trying) | | |<--------------------------| | | |--+ Negotiate media | | | | with UAC and map | | |<-+ tags and labels | | 200 OK | | |<--------------------------| | 200 OK | | |<------------------| | | ACK | | |------------------>| | | | ACK | | |-------------------------->| | | | |<<###########################################>>| | RTP Media Stream(s) flowing | |<<###########################################>>| | | | . . . . . .
| Figure 6: 3PCC Sequence Diagram |
The UAC first places a call to a SIP URI the AS is responsible of. The specific URI is not relevant to the examples, since the application logic behind the mapping between a URI and the service it provides is a matter that is important only to the AS: so, a generic 'sip:example@as.com' is used in all the examples, whereas the service this URI is associated with in the AS logic is mapped scenario by scenario to the case under exam. The UAC INVITE is treated as envisaged in [I‑D.ietf‑mediactrl‑architecture] (Melanchuk, T., “An Architectural Framework for Media Server Control,” November 2008.): the INVITE is forwarded by the AS to the MS in a 3PCC fashion, without the SDP provided by the UAC being touched, thus to have the session fully negotiated by the MS for what concerns its description. The MS matches the UAC's offer with its own capabilities and provides its answer in a 200 OK. This answer is then forwarded, again without the SDP contents being touched, by the AS to the UAC it is intended for. This way, while the SIP signaling from the UAC is terminated to the AS, all the media would start directly flowing between the UAC and the MS.
As a consequence of this negotiation, one or more media connections are created between the MS and the UAC. They are then addressed, when needed, by the AS and the MS by means of the tags concatenation as specified in [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.).
TBD. SIP negotiation -> tags and labels.
(Figure not available yet).
| Figure 7: 3PCC SIP Signaling |
As a result of the 3PCC negotiation, the following relevant information is retrieved:
These three identifiers allow the AS and MS to univocally and unambiguously address to each other the connections associated with the related UAC, specifically:
The mapping the AS makes between the UACs<->AS and the AS<->MS SIP dialogs is instead out of scope for this document: we just assume that the AS knows how to address the right connection according to the related session it has with a UAC (e.g. to play an announcement to a specific UAC).
| TOC |
The echo test is the simpliest example scenario that can be achieved by means of a Media Server. It basically consists of a UAC directly or indirectly "talking" to itself. A media perspective of such a scenario is depicted in Figure 8 (Echo Test: Media Perspective).
+-------+ A (RTP) +--------+
| UAC |=========================>| Media |
| A |<=========================| Server |
+-------+ A (RTP) +--------+
| Figure 8: Echo Test: Media Perspective |
From the framework point of view, when the UAC's leg is not attached to anything yet, what appears is described in Figure 9 (Echo Test: UAC Media Leg not attached): since there's no connection involving the UAC yet, the frames it might be sending are discarded, and nothing is sent to it (except for silence, if it is requested to be transmitted).
MS
+------+
UAC | |
o----->>-------x |
o.....<<.......x |
| |
+------+
| Figure 9: Echo Test: UAC Media Leg not attached |
Starting from these considerations, two different approaches to the Echo Test scenario are explored in this document in the following paragraphes:
| TOC |
In the Direct Echo Test approach, the UAC is directly connected to itself. This means that, as depicted in Figure 10 (Echo Test: Direct Echo (self connection)), each frame the MS receives from the UAC is sent back to it in real-time.
MS
+------+
UAC | |
o----->>-------@ |
o-----<<-------@ |
| |
+------+
| Figure 10: Echo Test: Direct Echo (self connection) |
In the framework this can be achieved by means of the conference control package, which is in charge of the task of joining connections and conferences.
A sequence diagram of a potential transaction is depicted in Figure 11 (Self Connection: Framework Transaction):
UAC AS MS
| | |
| | 1. CONTROL (join UAC to itself) |
| |++++++++++++++++++++++++++++++++>>|
| | |--+ self
| | | | join
| | 2. 200 OK |<-+ UAC
| |<<++++++++++++++++++++++++++++++++|
| | |
|<<######################################################>>|
| Now the UAC is echoed back everything |
|<<######################################################>>|
| | |
. . .
. . .
| Figure 11: Self Connection: Framework Transaction |
All the transaction steps have been numbered to ease up the understanding and the following of the subsequent explaination lines:
The complete transaction, that is the full bodies of the exchanged messages, is provided in the following lines:
1. AS -> MS (SCFW CONTROL) -------------------------- SCFW 74b0dc511949 CONTROL Control-Package: msc-conf-audio/1.0 Content-Type: text/xml Content-Length: 87 <?xml version="1.0"?> <join id1="1536067209~913cd14c" \ id2="1536067209~913cd14c"> </join> 2. AS <- MS (SCFW 200 OK) ----------------------------------- SCFW 74b0dc511949 200 Content-Type: text/xml Content-Length: 70 <?xml version="1.0"?> <response status="200" reason="Join successful"/>
| TOC |
In the Recording-based Echo Test approach, instead, the UAC is NOT directly connected to itself, but indirectly. This means that, as depicted in Figure 12 (Echo Test: Recording involved), each frame the MS receives from the UAC is first recorded: then, when the recording process is ended, the whole recorded frames are played back to the UAC as an announcement.
MS
+------+
UAC | |
o----->>-------+~~~~~> (recording.wav) ~~+
o-----<<-------+ | |
| ^ | v
+--|---+ |
+~~~~~~~~~~~<<~~~~~~~~~~~~+
| Figure 12: Echo Test: Recording involved |
In the framework this can be achieved by means of the basic IVR control package, which is in charge of the task of recording and playout. However, the whole scenario cannot be accomplished in a single transaction; at least two steps, in fact, need to be followed:
This means that two separate transactions need to be invoked. A sequence diagram of a potential multiple transaction is depicted in Figure 13 (Recording-based Echo: Two Framework Transactions):
UAC AS MS | | | | | A1. CONTROL (record for 10s) | | |++++++++++++++++++++++++++++++++>>| | | A2. 202 | | |<<++++++++++++++++++++++++++++++++| | | A3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| prepare & | | A4. 200 OK |--+ start | |++++++++++++++++++++++++++++++++>>| | the | | A5. REPORT (terminate) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | A6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "This is an echo test: tell something" | |<<########################################################| | | | |########################################################>>| | 10s of audio from the UAC is recorded |--+ save |########################################################>>| | in a | | |<-+ file | | B1. CONTROL (<recordinfo>) | | |<<++++++++++++++++++++++++++++++++| | Use recorded +--| B2. 200 OK | | file to play | |++++++++++++++++++++++++++++++++>>| | announcement +->| | | | C1. CONTROL (play recorded) | | |++++++++++++++++++++++++++++++++>>| | | C2. 202 | | |<<++++++++++++++++++++++++++++++++| | | C3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| prepare & | | C4. 200 OK |--+ start | |++++++++++++++++++++++++++++++++>>| | the | | C5. REPORT (terminate) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | C6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "Can you hear me? It's me, UAC, talking" | |<<########################################################| | | | | | D1. CONTROL (<promptinfo>) | | |<<++++++++++++++++++++++++++++++++| | | D2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . .
| Figure 13: Recording-based Echo: Two Framework Transactions |
Notice how the AS-originated CONTROL transactions are terminated as soon as the requested dialogs start: as specified in [I‑D.boulton‑ivr‑control‑package] (Boulton, C., Melanchuk, T., and S. McGlashan, “A Basic Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework,” February 2008.), the MS makes use of a framework CONTROL message to report the result of the dialog and how it has proceeded. The two transactions (the AS-generated CONTROL request and the MS-generated CONTROL event) are correlated by means of the associated dialog identifier, as it will be clearer from the following lines. As before, all the transaction steps have been numbered to ease up the understanding and the following of the subsequent explaination lines. Besides, the two transactions are distinguished by the preceding letter (A,B=recording, C,D=playout).
Now that the first transaction has ended, the AS has the 10s recording of the UAC talking. It can let the UAC hear it by having the MS play it to the MS as an announcement:
As in the previous paragraph, the whole SCFW interaction is provided for a more in depth evaluation of the protocol interaction.
A1. AS -> MS (SCFW CONTROL, record) ----------------------------------- SCFW 74b0dc511949 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Type: text/xml Content-Length: 354 <?xml version="1.0"?> <dialogstart connectionid="1536067209~913cd14c"> <basicivr> <prompt iterations="1"> <media src="http://www.ms.org/prompts/connected.wav" \ type="audio/wav"/> </prompt> <record maxtime="10s" dtmfterm="false" beep="true"/> </basicivr> </dialogstart> A2. AS <- MS (SCFW 202) ----------------------- SCFW 74b0dc511949 202 A3. AS <- MS (SCFW REPORT pending) ---------------------------------- SCFW 74b0dc511949 REPORT Seq: 1 Status: pending Timeout: 10 A4. AS -> MS (SCFW 200, ACK to 'REPORT pending') ------------------------------------------------ SCFW 74b0dc511949 200 Seq: 1 A5. AS <- MS (SCFW REPORT terminate) ------------------------------------ SCFW 74b0dc511949 REPORT Seq: 2 Status: terminate Timeout: 10 Content-Type: text/xml Content-Length: 88 <?xml version="1.0"?> <response status="200" \ reason="Dialog started" dialogid="05ded7b"/> A6. AS -> MS (SCFW 200, ACK to 'REPORT terminate') -------------------------------------------------- SCFW 74b0dc511949 200 Seq: 2 B1. AS <- MS (SCFW REPORT terminate) ------------------------------------ SCFW 4rgth45632d1 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Type: text/xml Content-Length: 197 <?xml version="1.0"?> <event dialogid="05ded7b"> <dialogexit status="1"> <recordinfo termmode="maxtime" duration="10000" \ size="161644" type="audio/wav" \ recording="http://www.ms.org/recording-05ded7b.wav"/> </dialogexit> </event> B2. AS -> MS (SCFW 200, ACK to 'CONTROL event') ----------------------------------------------- SCFW 4rgth45632d1 200 C1. AS -> MS (SCFW CONTROL, play) --------------------------------- SCFW 238e1f2946e8 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Type: text/xml Content-Length: 319 <?xml version="1.0"?> <dialogstart connectionid="1536067209~913cd14c"> <basicivr> <prompt iterations="1"> <media src="http://www.ms.org/recording-05ded7b.wav" \ type="audio/wav"/> </prompt> </basicivr> </dialogstart> C2. AS <- MS (SCFW 202) ----------------------- SCFW 238e1f2946e8 202 C3. AS <- MS (SCFW REPORT pending) ---------------------------------- SCFW 238e1f2946e8 REPORT Seq: 1 Status: pending Timeout: 10 C4. AS -> MS (SCFW 200, ACK to 'REPORT pending') ------------------------------------------------ SCFW 238e1f2946e8 200 Seq: 1 C5. AS <- MS (SCFW REPORT terminate) ------------------------------------ SCFW 238e1f2946e8 REPORT Seq: 2 Status: terminate Timeout: 10 Content-Type: text/xml Content-Length: 88 <?xml version="1.0"?> <response status="200" \ reason="Dialog started" dialogid="6faf4e0"/> C6. AS -> MS (SCFW 200, ACK to 'REPORT terminate') -------------------------------------------------- SCFW 238e1f2946e8 200 Seq: 2 D1. AS <- MS (SCFW CONTROL event) --------------------------------- SCFW g56dhg73g8r5 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Type: text/xml Content-Length: 165 <?xml version="1.0"?> <event dialogid="6faf4e0"> <dialogexit status="1"> <promptinfo termmode="completed" \ duration="10000" iterations="1"/> </dialogexit> </event> D2. AS -> MS (SCFW 200, ACK to 'CONTROL event') ----------------------------------------------- SCFW g56dhg73g8r5 200
| TOC |
Another scenario that might involve the interaction between an AS and a MS is the classic phone call between two UACs. In fact, even though the most straightforward way to achieve this would be to let the UACs negotiate the session and the media to make use of between themselves, there are cases when the services provided by a MS might come in handy for phone calls as well.
One of these cases is when the two UACs have no common supported codecs: having the two UACs directly negotiate the session would result in a session with no available media. Involving the MS as a transcoder would instead allow the two UACs to communicate anyway. Another interesting case is when the AS (or any other entity the AS is working in behalf of) is interested in manipulating or monitoring the media session between the UACs, e.g. to record the conversation: a similar scenario will be dealt with in Section 6.2.2 (Conference-based Approach).
Before proceeding in looking at how such a scenario might be accomplished by means of the Media Control Channel Framework, it is worth spending a couple of words upon how the SIP signaling involving all the interested parties might look like. In fact in such a scenario a 3PCC approach is absolutely needed. An example is provided in Figure 14 (Phone Call: Example of 3PCC), and takes into account the recommendations provided in [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),” April 2004.). Only an explainatory sequence diagram is provided, without delving into the details of the exchanged SIP messages.
UAC(1) UAC(2) AS MS | | | | | INVITE (offer A) | | |---------------------------------->| | | | 100 Trying | | |<----------------------------------| | | | INVITE (no offer) | | | |<--------------------| | | | 180 Ringing | | | |-------------------->| | | | 180 Ringing | | |<----------------------------------| INVITE (offer A) | | | |-------------------------->| | | | 200 OK (offer A') | | | |<--------------------------| | | | ACK | | | |-------------------------->| | | 200 OK (offer B) | | | |-------------------->| INVITE (offer B) | | | |-------------------------->| | | | 200 OK (offer B') | | | |<--------------------------| | | | ACK | | | ACK (offer B') |-------------------------->| | |<--------------------| | | | 200 OK (offer A') | | |<----------------------------------| | | ACK | | | |---------------------------------->| | | | | | . . . . . . . .
| Figure 14: Phone Call: Example of 3PCC |
In the example, the UAC1 wants to place a phone call to UAC2. To do so, it sends an INVITE to the AS with its offer A. The AS sends an offerless INVITE to UAC2. When the UAC2 responds with a 180, the same message is forwarded by the AS to the UAC1 to notify it the callee is ringing. In the meanwhile, the AS also adds a leg to the MS for UAC1, as explained in the previous sections: to do so it of course makes use of the offer A the UAC1 made. Once the UAC2 accepts the call, by providing its own offer B in the 200, the AS adds a leg for it too to the MS. At this point, the negotiation can be completed by providing the two UACs with the SDP answer negotiated by the MS with them (A' and B' respectively).
This is only one way to deal with the signaling, and shall not absolutely be considered as a mandatory approach of course.
Once the negotiation is over, the two UACs are not in communication yet. In fact, it's up to the AS now to actively trigger the MS into attaching their media streams to each other someway, by referring to the connection identifiers associated with the UACs as explained previously. This document presents two different approaches that might be followed, according to what needs to be accomplished. A generic media perspective of the phone call scenario is depicted in Figure 15 (Phone Call: Media Perspective): the MS is basically in the media path between the two UACs.
+-------+ A (RTP) +--------+ A (RTP) +-------+ | UAC |===================>| Media |===================>| UAC | | A |<===================| Server |<===================| B | +-------+ B (RTP) +--------+ B (RTP) +-------+
| Figure 15: Phone Call: Media Perspective |
From the framework point of view, when the UACs' leg are not attached to anything yet, what appears is described in Figure 16 (Phone Call: UAC Media Leg not attached): since there are no connections involving the UACs yet, the frames they might be sending are discarded, and nothing is sent to them (except for silence, if it is requested to be transmitted).
MS
+--------------+
UAC A | | UAC B
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
+--------------+
| Figure 16: Phone Call: UAC Media Leg not attached |
| TOC |
The Direct Connection is the easiest and more straightforward approach to get the phone call between the two UACs to work. The idea is basically the same as the one in the Direct Echo approach: a <join> directive is used to directly attach one UAC to the other, by leaving the MS to only deal with the transcoding/adaption of the flowing frames, if needed.
This approach is depicted in Figure 17 (Phone Call: Direct Connection).
MS
+--------------+
UAC A | | UAC B
o----->>-------+~~~>>~~~+------->>-----o
o-----<<-------+~~~<<~~~+-------<<-----o
| |
+--------------+
| Figure 17: Phone Call: Direct Connection |
UAC1 UAC2 AS MS | | | | | | | 1. CONTROL (join UAC1 to UAC2) | | | |++++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC1 | | | 2. 200 OK |<-+ UAC2 | | |<<++++++++++++++++++++++++++++++++++| | | | | |<<#######################################################>>| | UAC1 can hear UAC2 talking | |<<#######################################################>>| | | | | | |<<###########################################>>| | | UAC2 can hear UAC1 talking | | |<<###########################################>>| | | | | |<*talking*>| | | . . . . . . . .
| Figure 18: Direct Connection: Framework Transactions |
TBD. Describe the framework transaction steps.
1. AS -> MS (SCFW CONTROL) -------------------------- SCFW 3fg58dd12s49 CONTROL Control-Package: msc-conf-audio/1.0 Content-Type: text/xml Content-Length: 89 <?xml version="1.0"?> <join id1="1536067209~913cd14c" \ id2="00c09fc35b07~d5d85047"> </join> 2. AS <- MS (SCFW 200 OK) ----------------------------------- SCFW 3fg58dd12s49 200 Content-Type: text/xml Content-Length: 70 <?xml version="1.0"?> <response status="200" reason="Join successful"/>
| TOC |
The approach described in Section 6.2.1 (Direct Connection) surely works for a basic phone call, but has drawbacks when some more advanced features are needed. For intance, you can't record the whole conversation, only the single connections, since no mixing is involved. In more advanced cases a different approach might be taken, like the conference-based approach described in this section.
The idea is to make use of a mixing entity in the MS that acts as a bridge between the two UACs: the presence of this entity allows for more customization on what needs to be done on the conversation, like the recording of the conversation that has been provided as example. The approach is depicted in Figure 19 (Phone Call: Conference-based Approach). The mixing functionality in the MS will be described in more detail in the following section (which deals with many conference-related scenarios), so only some hints will be provided here for a basic comprehension of the approach.
MS
+---------------+
UAC A | | UAC B
o----->>-------+~~>{#}::>+:::::::>>:::::o
o:::::<<:::::::+<::{#}<~~+-------<<-----o
| : |
| : |
+-------:-------+
:
+::::> (conversation.wav)
| Figure 19: Phone Call: Conference-based Approach |
To identify a single sample scenario, let's consider a phone call the AS wants to be recorded.
Figure 20 (Conference-based Approach: Framework Transactions) shows how this could be accomplished in the Media Control Channel Framework: the example, as usual, hides the previous interaction between the UACs and the AS, and instead focuses on the control channel operations and what follows.
UAC1 UAC2 AS MS | | | | | | | A1. CONTROL (create conference) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ create | | | | | conf and | | | A2. 200 OK (conferenceid=Y) |<-+ its ID | | |<<++++++++++++++++++++++++++++++++| | | | | | | | B1. CONTROL (record for 10s) | | | |++++++++++++++++++++++++++++++++>>| | | | B2. 202 | | | |<<++++++++++++++++++++++++++++++++| | | | B3. REPORT (pending) | | | |<<++++++++++++++++++++++++++++++++| | | | B4. 200 OK |--+ start | | |++++++++++++++++++++++++++++++++>>| | the | | | B5. REPORT (terminate) |<-+ dialog | | |<<++++++++++++++++++++++++++++++++| | Recording +--| B6. 200 OK | | of the mix | |++++++++++++++++++++++++++++++++>>| | has started +->| | | | | C1. CONTROL (join UAC1<->confY) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC1 & | | | C2. 200 OK |<-+ conf Y | | |<<++++++++++++++++++++++++++++++++| | | | | |<<####################################################>>| | Now the UAC1 is mixed in the conference | |<<####################################################>>| | | | | | | | D1. CONTROL (join UAC2<->confY) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC2 & | | | D2. 200 OK |<-+ conf Y | | |<<++++++++++++++++++++++++++++++++| | | | | | |<<########################################>>| | | Now the UAC2 is mixed too | | |<#########################################>>| | | | | |<*talking*>| | | | | | | . . . . . . . .
| Figure 20: Conference-based Approach: Framework Transactions |
TBD. Describe the framework transaction steps.
(Framework transactions not available yet).
| TOC |
Another application that typically makes use of the services a MS can provide is Voice Mail. In fact, while it is clear that many of its features are part of the application logic (e.g. the mapping of a URI with a specific user's voice mailbox, the list of messages and their properties, and so on), the actual media work is accomplished through the MS. Features needed by a VoiceMail application include the ability to record a stream and play it back anytime later, give verbose announcements regarding the status of the application, controlling the playout of recorded messages by means of VCR controls and so on, all features which are supported by the MS through the Basic IVR package.
Without delving into the details of a full VoiceMail application and all its possible use cases, this section will cover a specific scenario, trying to deal with as many as possible interactions that may happen between the AS and the MS in such a context. The covered scenario, depicted as a sequence diagram in Figure 21 (Voice Mail: Framework Transactions), will be the following:
This is a quite oversimplified scenario, considering it doesn't even allow the UAC to choose which received message to play. Nevertheless, it gives us the chance to deal with variable announcements and VCR controls, two typical features a Voice Mail application would almost always take advantage of. Besides, other features a Voice Mail application would rely upon (e.g. recording streams, event driven IVR menus and so on) have aready been introduced in previous sections, and so representing them would be redundant.
UAC AS MS | | | | | A1. CONTROL (play variables) | | |++++++++++++++++++++++++++++++++>>| | | A2. 202 | | |<<++++++++++++++++++++++++++++++++| | | A3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| prepare & | | A4. 200 OK |--+ start | |++++++++++++++++++++++++++++++++>>| | the | | A5. REPORT (terminate) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | A6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "5 mails, latest received on ..." | |<<########################################################| | | | | | B1. CONTROL (<promptinfo>) | | |<<++++++++++++++++++++++++++++++++| | | B2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | | | C1. CONTROL (play and VCR) | | |++++++++++++++++++++++++++++++++>>| | | C2. 202 | | |<<++++++++++++++++++++++++++++++++| | | C3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| prepare & | | C4. 200 OK |--+ start | |++++++++++++++++++++++++++++++++>>| | the | | C5. REPORT (terminate) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | C6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "Hi there, I tried to call you but..." |--+ |<<########################################################| | handle | | | | VCR |########################################################>>| | driven | The UAC controls the playout using DTMF | | (DTMF) |########################################################>>| | playout | | |<-+ | | D1. CONTROL (<collectinfo>) | | |<<++++++++++++++++++++++++++++++++| | | D2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . .
| Figure 21: Voice Mail: Framework Transactions |
TBD. Describe the framework transaction steps.
A1. AS -> MS (SCFW CONTROL, play) --------------------------------- SCFW 1gffh68hydx0 CONTROL Control-Package: msc-ivr-basic Content-Type: text/xml Content-Length: 271 <?xml version="1.0"?> <dialogstart conferenceid="1cc1a27"> <basicivr> <prompt bargein=false" maxduration="15s"> <media src="http://www.ms.org/prompts/youhave.wav" type="audio/wav"/> <variable value="5" type="digits"/> <media src="http://www.ms.org/prompts/mails.wav" type="audio/wav"/> <media src="http://www.ms.org/prompts/lastreceived.wav" type="audio/wav"/> <variable value="2008-03-07" type="date" format="ymd"/> <variable value="11:09" type="time" format="t24"/> </prompt> </basicivr> </dialogstart> A2. AS <- MS (SCFW 202) ----------------------- SCFW 1gffh68hydx0 202 A3. AS <- MS (SCFW REPORT pending) ---------------------------------- SCFW 1gffh68hydx0 REPORT Seq: 1 Status: pending Timeout: 10 A4. AS -> MS (SCFW 200, ACK to 'REPORT pending') ------------------------------------------------ SCFW 1gffh68hydx0 200 Seq: 1 A5. AS <- MS (SCFW REPORT terminate) ------------------------------------ SCFW 1gffh68hydx0 REPORT Seq: 2 Status: terminate Timeout: 15 Content-Type: text/xml Content-Length: 88 <?xml version="1.0"?> <response status="200" reason="Dialog started" \ dialogid="6jwwf5r"/> A6. AS -> MS (SCFW 200, ACK to 'REPORT terminate') -------------------------------------------------- SCFW 1gffh68hydx0 200 Seq: 2 B1. AS <- MS (SCFW CONTROL event) --------------------------------- SCFW hf47fg474fge CONTROL Control-Package: msc-ivr-basic/1.0 Content-Type: text/xml Content-Length: 126 <?xml version="1.0"?> <event dialogid="6jwwf5r"> <dialogexit status="1"> <promptinfo duration="12300" termmode="completed"/> <dialogexit/> </event> B2. AS -> MS (SCFW 200, ACK to 'CONTROL event') ----------------------------------------------- SCFW hf47fg474fge 200 C1. AS -> MS (SCFW CONTROL, VCR) -------------------------------- SCFW p0ofgh35vzx1 CONTROL Control-Package: msc-ivr-basic Content-Type: text/xml Content-Length: 271 <?xml version="1.0"?> <dialogstart conferenceid="1cc1a27"> <basicivr> <prompt maxduration="300s"> <media src="http://www.ms.org/recordings/recording-54fcb22.wav" type="audio/wav"/> </prompt> <collect ffkey="6" rwkey="4" pausekey="7" resumekey="9"/> </basicivr> </dialogstart> C2. AS <- MS (SCFW 202) ----------------------- SCFW p0ofgh35vzx1 202 C3. AS <- MS (SCFW REPORT pending) ---------------------------------- SCFW p0ofgh35vzx1 REPORT Seq: 1 Status: pending Timeout: 10 C4. AS -> MS (SCFW 200, ACK to 'REPORT pending') ------------------------------------------------ SCFW p0ofgh35vzx1 200 Seq: 1 C5. AS <- MS (SCFW REPORT terminate) ------------------------------------ SCFW p0ofgh35vzx1 REPORT Seq: 2 Status: terminate Timeout: 15 Content-Type: text/xml Content-Length: 88 <?xml version="1.0"?> <response status="200" reason="Dialog started" \ dialogid="1aa30g5"/> C6. AS -> MS (SCFW 200, ACK to 'REPORT terminate') -------------------------------------------------- SCFW p0ofgh35vzx1 200 Seq: 2 D1. AS <- MS (SCFW CONTROL event) --------------------------------- SCFW 4rfg34fg21ge CONTROL Control-Package: msc-ivr-basic/1.0 Content-Type: text/xml Content-Length: 126 <?xml version="1.0"?> <event dialogid="1aa30g5"> <dialogexit status="1"> <collectinfo dtmf="46679" termmode="match"/> <dialogexit/> </event> D2. AS -> MS (SCFW 200, ACK to 'CONTROL event') ----------------------------------------------- SCFW 4rfg34fg21ge 200
| TOC |
One of the most important services the MS must be able to provide is mixing. This involves mixing media streams from different sources, and delivering the resulting mix(es) to each interested party, often according to per-user policies, settings and encoding. A typical scenario involving mixing is of course media conferencing. In such a scenario, the media sent by each participant is mixed, and each participant typically receives the overall mix excluding its own contribtion and encoded in the format it negotiated. This example points out in a quite clear way how mixing must take care of the profile of each involved entity.
A media perspective of such a scenario is depicted in Figure 22 (Conference: Media Perspective).
+-------+
| UAC |
| C |
+-------+
" ^
C (RTP) " "
" "
" " A+B (RTP)
v "
+-------+ A (RTP) +--------+ A+C (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B+C (RTP) +--------+ B (RTP) +-------+
| Figure 22: Conference: Media Perspective |
From the framework point of view, when the UACs' legs are not attached to anything yet, what appears is described in Figure 23 (Conference: UAC Legs not attached): since there are no connections involving the UACs yet, the frames they might be sending are discarded, and nothing is sent back to them either (except for silence, if it is requested to be transmitted).
MS
+----------------+
UAC A | | UAC B
o----->>-------x x.......>>.....o
o.....<<.......x x-------<<-----o
| |
| |
| xx |
| |. |
+-------|.-------+
|.
^v
^v
|.
oo
UAC C
| Figure 23: Conference: UAC Legs not attached |
The next subsections will cover several typical scenarios involving mixing and conferencing as a whole, specifically:
All the above mentioned scenarios depend on the availability of a mixing entity. Such an entity is provided in the Media Control Channel Framework by the conferencing package. This package in fact, besides allowing for the joining of media sources between each other as seen in the Direct Echo Test section, enables the creation of abstract connections that can be joined to multiple connections: these abstract connections, called conferences, mix the contribution of each attached connection and feed them accordingly (e.g. a connection with 'sendrecv' property would be able to contribute to the mix and to listen to it, while a connection with a 'recvonly' property would only be able to listen to the overall mix but not to actively contribute to it).
That said, each of the above mentioned scenarios will start more or less in the same way: by the creation of a conference connection (or more than one, as needed in some cases) to be subsequently referred to when it comes to mixing. A typical framework transaction to crete a new conference instance in the Media Control Channel Framework is depicted in Figure 24 (Conference: Framework Transactions):
AS MS
| |
| 1. CONTROL (create conference) |
|++++++++++++++++++++++++++++++++>>|
| |--+ create
| | | conf and
| 2. 200 OK (conferenceid=Y) |<-+ its ID
|<<++++++++++++++++++++++++++++++++|
map URI +--| |
X with | | |
conf Y +->| |
| |
. .
. .
| Figure 24: Conference: Framework Transactions |
The call flow is quite straightforward, and can typically be summarized in the following steps:
1. AS -> MS (SCFW CONTROL) ------------------------ SCFW 238e1f2946e8 CONTROL Control-Package: msc-conf-audio/1.0 Content-Type: text/xml Content-Length: 311 <?xml version="1.0"?> <createconference> <audio-mixing mix-type="nbest"/> <reserved-talkers>5</reserved-talkers> <subscribe> <notify name="active-talkers"> <data> <item name="interval" value="3s"/> </data> </notify> </subscribe> <reserved-listeners>10</reserved-listeners> </createconference> 2. AS <- MS (SCFW 200) ---------------------- SCFW 238e1f2946e8 200 Content-Type: text/xml Content-Length: 91 <?xml version="1.0"?> <response status="200" reason="Conference created" \ conferenceid="1cc1a27"/>
| TOC |
As already introduced before, the simplest use an AS can make of a conference instance is simple bridging. In this scenario, the conference instance just acts as a bridge for all the participants that are attached to it. The bridge takes care of transcoding, if needed (in general, different participants may make use of different codecs for their streams), echo cancellation (each participant will receive the overall mix excluding their own contribution) and per-participant mixing (each participant may receive different mixed streams, according to what it needs/is allowed to send/receive). This assumes of course that each interested participant must be joined somehow to the bridge in order to indirectly communicate with the other paricipants. From the media perspective, the scenario can be seen as depicted in Figure 25 (Conference: Simple Bridging).
MS
+-----------------+
UAC A | | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: |
| |v |
| ++ |
| |: |
+--------|:-------+
|:
^v
^v
|:
oo
UAC C
| Figure 25: Conference: Simple Bridging |
In the framework, the first step is obviously to create a new conference instance as seen in the introductory section (Figure 24 (Conference: Framework Transactions)). Assuming a conference instance has already been created, bridging participants to it is quite straightforward, and can be accomplished as already seen in the Direct Echo Test Scenario: the only difference here is that each participant is not directly connected to itself (Direct Echo) or another UAC (Direct Connection) but to the bridge instead. Figure 26 (Simple Bridging: Framework Transactions (1)) shows the example of two different UACs joining the same conference: the example, as usual, hides the previous interaction between each of the two UACs and the AS, and instead focuses on what the AS does to actually join the participants to the bridge so that they can interact in a conference.
UAC1 UAC2 AS MS | | | | | | | A1. CONTROL (join UAC1 and confY) | | | |++++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC1 & | | | A2. 200 OK |<-+ conf Y | | |<<++++++++++++++++++++++++++++++++++| | | | | |<<######################################################>>| | Now the UAC1 is mixed in the conference | |<<######################################################>>| | | | | | | | B1. CONTROL (join UAC2 and confY) | | | |++++++++++++++++++++++++++++++++++>>| | | | |--+ join | | | | | UAC2 & | | | B2. 200 OK |<-+ conf Y | | |<<++++++++++++++++++++++++++++++++++| | | | | | |<<###########################################>>| | | Now the UAC2 too is mixed in the conference | | |<<###########################################>>| | | | | . . . . . . . .
| Figure 26: Simple Bridging: Framework Transactions (1) |
TBD. Describe the framework transaction steps.
A1. AS -> MS (SCFW CONTROL) -------------------------- SCFW 3fg58dd12s49 CONTROL Control-Package: msc-conf-audio/1.0 Content-Type: text/xml Content-Length: 75 <?xml version="1.0"?> <join id1="1536067209~913cd14c" \ id2="1cc1a27"> </join> A2. AS <- MS (SCFW 200 OK) ----------------------------------- SCFW 3fg58dd12s49 200 Content-Type: text/xml Content-Length: 70 <?xml version="1.0"?> <response status="200" reason="Join successful"/> B1. AS -> MS (SCFW CONTROL) -------------------------- SCFW 6fg25gds2451 CONTROL Control-Package: msc-conf-audio/1.0 Content-Type: text/xml Content-Length: 77 <?xml version="1.0"?> <join id1="00c09fc35b07~d5d85047" \ id2="1cc1a27"> </join> B2. AS <- MS (SCFW 200 OK) ----------------------------------- SCFW 6fg25gds2451 200 Content-Type: text/xml Content-Length: 70 <?xml version="1.0"?> <response status="200" reason="Join successful"/>
Once one or more participants have been attached to the bridge, their connections and how their media are handled by the bridge can be dynamically manipulated by means of another directive, called <modifyjoin>: a typical use case for this directive is the change of direction of an existing media (e.g. a previously speaking participant is muted, which means its media direction changes from 'sendrecv' to 'recvonly'). Figure 27 (Simple Bridging: Framework Transactions (2)) shows how a framework transaction requesting such a directive might appear.
UAC1 UAC2 AS MS | | | | | | | 1. CONTROL (modifyjoin UAC1) | | | |++++++++++++++++++++++++++++++++>>| | | | |--+ modify | | | | | join | | | 2. 200 OK |<-+ settings | | |<<++++++++++++++++++++++++++++++++| | | | | |<<######################################################| | Now the UAC1 can receive but not send (recvonly) | |<<######################################################| | | | | . . . . . . . .
| Figure 27: Simple Bridging: Framework Transactions (2) |
TBD. Describe the framework transaction steps.
1. AS -> MS (SCFW CONTROL) -------------------------- SCFW 2fdgrt46az11 CONTROL Control-Package: msc-conf-audio/1.0 Content-Type: text/xml Content-Length: 133 <?xml version="1.0"?> <modifyjoin id1="1536067209~913cd14c" \ id2="1cc1a27"> <stream media="audio" label="25547c8" \ direction="recvonly"/> </modifyjoin> 2. AS <- MS (SCFW 200 OK) ----------------------------------- SCFW 2fdgrt46az11 200 Content-Type: text/xml Content-Length: 76 <?xml version="1.0"?> <response status="200" reason="Modifyjoin successful"/>
| TOC |
The previous scenario can be enriched with additional features often found in existing conferencing systems. Typical examples include IVR-based menus (e.g. the DTMF collection for PIN-based conference access), partial and complete recordings in the conference (e.g. for the "state your name" functionality and recording of the whole conference), private and global announcements and so on. All of this can be achieved by means of the functionality provided by the MS. In fact, even if the conferencing and IVR features come from different packages, the AS can interact with both of them and achieve complex results by correlating the results of different transactions in its application logic.
From the media and framework perspective, a typical rich conferencing scenario can be seen as it is depicted in Figure 28 (Conference: Rich Conference Scenario).
MS
+-------- (announcement.wav)
(conference_recording.wav) <:::::+|
:|
+--------:|--------+
UAC A | :v | UAC B
o----->>-------+~~~>{##}:::>+:::::::>>:::::o
o:::::<<:::::::+<:::{##}<~~~+-------<<-----o
| ^: | |
| |v v |
| ++ * (collect DTMF, get name)
| |: |
+--------|:--------+
|:
^v
^v
|:
oo
UAC C
| Figure 28: Conference: Rich Conference Scenario |
To identify a single sample scenario, let's consider this sequence for a participant joining a conference (which again we assume has already been created):
Figure 29 (Rich Conference Scenario: Framework Transactions) shows a single UAC joining a conference: the example, as usual, hides the previous interaction between the UAC and the AS, and instead focuses on what the AS does to actually interact with the participant and join it to the conference bridge.
UAC AS MS | | | | | A1. CONTROL (request DTMF PIN) | | |++++++++++++++++++++++++++++++++>>| | | A2. 202 | | |<<++++++++++++++++++++++++++++++++| | | A3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| | | A4. 200 OK |--+ start | |++++++++++++++++++++++++++++++++>>| | the | | A5. REPORT (terminate) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | A6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "Please digit the PIN number to join the conference" | |<<########################################################| | | | |########################################################>>| | DTMF digits are collected |--+ get |########################################################>>| | DTMF | | |<-+ digits | | B1. CONTROL (<collectinfo>) | | |<<++++++++++++++++++++++++++++++++| | Compare DTMF +--| B2. 200 OK | | digits with | |++++++++++++++++++++++++++++++++>>| | the PIN number +->| | | | C1. CONTROL (record name) | | |++++++++++++++++++++++++++++++++>>| | | C2. 202 | | |<<++++++++++++++++++++++++++++++++| | | C3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| | | C4. 200 OK |--+ start | |++++++++++++++++++++++++++++++++>>| | the | | C5. REPORT (terminate) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | C6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "Please state your name after the beep" | |<<########################################################| | | | |########################################################>>| | Audio from the UAC is recorded (until timeout or DTMF) |--+ save |########################################################>>| | in a | | |<-+ file | | D1. CONTROL (<recordinfo>) | | |<<++++++++++++++++++++++++++++++++| | Store recorded +--| D2. 200 OK | | file to play | |++++++++++++++++++++++++++++++++>>| | announcement in +->| | | conference later | | | | E1. CONTROL (join UAC & confY) | | |++++++++++++++++++++++++++++++++>>| | | |--+ join | | | | UAC & | | E2. 200 OK |<-+ conf Y | |<+++++++++++++++++++++++++++++++++| | | | |<<######################################################>>| | UAC is now included in the mix of the conference | |<<######################################################>>| | | | | | F1. CONTROL (play name on confY) | | |++++++++++++++++++++++++++++++++>>| | | F2. 202 | | |<<++++++++++++++++++++++++++++++++| | | F3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| | | F4. 200 OK |--+ start | |++++++++++++++++++++++++++++++++>>| | the | | F5. REPORT (terminate) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | F6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | Global announcement: "Simon has joined the conference" | |<<########################################################| | | | | | G1. CONTROL (<promptinfo>) | | |<<++++++++++++++++++++++++++++++++| | | G2. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . .
| Figure 29: Rich Conference Scenario: Framework Transactions |
TBD. Describe the framework transaction steps.
A1. AS -> MS (SCFW CONTROL, collect) ------------------------------------ SCFW 238e1f2946e8 CONTROL Control-Package: msc-ivr-basic Content-Type: text/xml Content-Length: 260 <?xml version="1.0"?> <dialogstart connectionid="1536067209~913cd14c"> <basicivr> <prompt bargein="false"> <media src="http://www.ms.org/prompts/getpin.wav" type="audio/wav"/> </prompt> <collect maxdigits="4" escapekey="*"/> </basicivr> </dialogstart> A2. AS <- MS (SCFW 202) ----------------------- SCFW 238e1f2946e8 202 A3. AS <- MS (SCFW REPORT pending) ---------------------------------- SCFW 238e1f2946e8 REPORT Seq: 1 Status: pending Timeout: 10 A4. AS -> MS (SCFW 200, ACK to 'REPORT pending') ------------------------------------------------ SCFW 238e1f2946e8 200 Seq: 1 A5. AS <- MS (SCFW REPORT terminate) ------------------------------------ SCFW 238e1f2946e8 REPORT Seq: 2 Status: terminate Timeout: 15 Content-Type: text/xml Content-Length: 88 <?xml version="1.0"?> <response status="200" reason="Dialog started" \ dialogid="2fe9bf0"/> A6. AS -> MS (SCFW 200, ACK to 'REPORT terminate') -------------------------------------------------- SCFW 238e1f2946e8 200 Seq: 2 B1. AS <- MS (SCFW CONTROL event) --------------------------------- SCFW 734227ed7ce9 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Type: text/xml Content-Length: 126 <?xml version="1.0"?> <event dialogid="2fe9bf0"> <dialogexit status="1"> <collectinfo dtmf="1234" termmode="match"/> <dialogexit/> </event> B2. AS -> MS (SCFW 200, ACK to 'CONTROL event') ----------------------------------------------- SCFW 734227ed7ce9 200 C1. AS -> MS (SCFW CONTROL, record) ----------------------------------- SCFW 2eb141f241b7 CONTROL Control-Package: msc-ivr-basic Content-Type: text/xml Content-Length: 257 <?xml version="1.0"?> <dialogstart connectionid="1536067209~913cd14c"> <basicivr> <prompt> <media src="http://www.ms.org/prompts/rec-name.wav" type="audio/wav"/> </prompt> <record beep="true" maxtime="5s"/> </basicivr> </dialogstart> C2. AS <- MS (SCFW 202) ----------------------- SCFW 2eb141f241b7 202 C3. AS <- MS (SCFW REPORT pending) ---------------------------------- SCFW 2eb141f241b7 REPORT Seq: 1 Status: pending Timeout: 10 C4. AS -> MS (SCFW 200, ACK to 'REPORT pending') ------------------------------------------------ SCFW 2eb141f241b7 200 Seq: 1 C5. AS <- MS (SCFW REPORT terminate) ------------------------------------ SCFW 2eb141f241b7 REPORT Seq: 2 Status: terminate Timeout: 15 Content-Type: text/xml Content-Length: 88 <?xml version="1.0"?> <response status="200" reason="Dialog started" \ dialogid="15b3128"/> C6. AS -> MS (SCFW 200, ACK to 'REPORT terminate') -------------------------------------------------- SCFW 2eb141f241b7 200 Seq: 2 D1. AS <- MS (SCFW CONTROL event) --------------------------------- SCFW 63300e4f3df1 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Type: text/xml Content-Length: 231 <?xml version="1.0"?> <event dialogid="15b3128"> <dialogexit status="1"> <recordinfo type="audio/wav" duration="3500" \ size="67500" termmode="dtmf" \ recording="http://www.ms.org/recordings/recording-15b3128.wav"/> <dialogexit/> </event> D2. AS -> MS (SCFW 200, ACK to 'CONTROL event') ----------------------------------------------- SCFW 63300e4f3df1 200 E1. AS -> MS (SCFW CONTROL, join) --------------------------------- SCFW 3fg58dd12s49 CONTROL Control-Package: msc-conf-audio/1.0 Content-Type: text/xml Content-Length: 75 <?xml version="1.0"?> <join id1="1536067209~913cd14c" \ id2="1cc1a27"> </join> E2. AS <- MS (SCFW 200 OK) -------------------------- SCFW 3fg58dd12s49 200 Content-Type: text/xml Content-Length: 70 <?xml version="1.0"?> <response status="200" reason="Join successful"/> F1. AS -> MS (SCFW CONTROL, play) --------------------------------- SCFW 515f007c5bd0 CONTROL Control-Package: msc-ivr-basic Content-Type: text/xml Content-Length: 271 <?xml version="1.0"?> <dialogstart conferenceid="1cc1a27"> <basicivr> <prompt> <media src="http://www.ms.org/recordings/recording-15b3128.wav" type="audio/wav"/> <media src="http://www.ms.org/prompts/hasjoined.wav" type="audio/wav"/> </prompt> </basicivr> </dialogstart> F2. AS <- MS (SCFW 202) ----------------------- SCFW 515f007c5bd0 202 F3. AS <- MS (SCFW REPORT pending) ---------------------------------- SCFW 515f007c5bd0 REPORT Seq: 1 Status: pending Timeout: 10 F4. AS -> MS (SCFW 200, ACK to 'REPORT pending') ------------------------------------------------ SCFW 515f007c5bd0 200 Seq: 1 F5. AS <- MS (SCFW REPORT terminate) ------------------------------------ SCFW 515f007c5bd0 REPORT Seq: 2 Status: terminate Timeout: 15 Content-Type: text/xml Content-Length: 88 <?xml version="1.0"?> <response status="200" reason="Dialog started" \ dialogid="0aa23bc"/> F6. AS -> MS (SCFW 200, ACK to 'REPORT terminate') -------------------------------------------------- SCFW 515f007c5bd0 200 Seq: 2 G1. AS <- MS (SCFW CONTROL event) --------------------------------- SCFW h345fgt264f9 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Type: text/xml Content-Length: 126 <?xml version="1.0"?> <event dialogid="0aa23bc"> <dialogexit status="1"> <promptinfo duration="3500" termmode="completed"/> <dialogexit/> </event> G2. AS -> MS (SCFW 200, ACK to 'CONTROL event') ----------------------------------------------- SCFW h345fgt264f9 200
| TOC |
TBD. (Add sequence diagrams and signaling issues; reference draft [I‑D.miniero‑bfcp‑control‑package] (Miniero, L., Romano, S., Even, R., and S. McGlashan, “A Binary Floor Control Protocol (BFCP) Control Package for the Media Control Channel Framework,” July 2008.))
(Figure not available yet.)
| Figure 30: Floor Control: Media Perspective |
(Figure not available yet.)
| Figure 31: Floor Control: UAC Legs not attached |
(Figure not available yet.)
| Figure 32: Floor Control: UAC Legs mixed and attached |
(Figure not available yet.)
| Figure 33: Floor Control: Framework Transactions |
| TOC |
TBD. (Reference RFC4579 [RFC4579] (Johnston, A. and O. Levin, “Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents,” August 2006.) and conference control package, which both use this scenario as conferencing example; focus on per-user policies for media mixing and delivery, e.g. who can hear what; use of multiple conferences and connections to achieve the scenario, as suggested in JSR309 as well; etc...).
************** +-------+
* A=Customer * | UAC |
* B=Agent * | C |
* C=Coach * +-------+
************** " ^
C (RTP) " "
" "
" " A+B (RTP)
v "
+-------+ A (RTP) +--------+ A+C (RTP) +-------+
| UAC |===================>| Media |===================>| UAC |
| A |<===================| Server |<===================| B |
+-------+ B (RTP) +--------+ B (RTP) +-------+
| Figure 34: Coaching Scenario: Media Perspective |
MS
+---------------------------+
| |
UAC A | | UAC B
o.....<<.......x x-------<<-----o
o----->>-------x x.......>>.....o
| |
| |
| |
| |
| xx |
| .| +
+------------v^-------------+
v^
.|
.|
oo
UAC C
| Figure 35: Coaching Scenario: UAC Legs not attached |
MS
+---------------------------+
| +~~~~~~~~~~+ |
UAC A | v | | UAC B
o-----<<-------+ +~+~~~~~<~~~~+-------<<-----o
o----->>-------+~~>[#]<~+ +------->>-----o
| | : ^ |
| +~~~~:~~~>[#]:::::::::+ |
| v ^ |
| : | |
| ::>::++ |
| :| +
+------------v^-------------+
v^
:|
:|
oo
UAC C
| Figure 36: Coaching Scenario: UAC Legs mixed and attached |
(Figure not available yet).
| Figure 37: Coaching Scenario: Framework Transactions |
(Framework transactions not available yet).
| TOC |
TBD. (Even more issues than in coaching scenario; of greater interest for conferencing, expecially XCON; as before, focus on per-user and per-conference settings; potential issues and how to deal with them; etc...).
(Figure not available yet.)
| Figure 38: Sidebars: Media Perspective |
(Figure not available yet.)
| Figure 39: Sidebars: UAC Legs not attached |
(Figure not available yet.)
| Figure 40: Sidebars: UAC Legs mixed and attached |
(Figure not available yet).
| Figure 41: Sidebars: Framework Transactions |
| TOC |
TBD. (None, since this is informational?)
| TOC |
The following are the major changes between the 00 and the 01 versions of the draft:
| TOC |
TBD.
| TOC |
| [RFC2234] | Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 2234, November 1997 (TXT, HTML, XML). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC2434] | Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 2434, October 1998 (TXT, HTML, XML). |
| [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 (TXT). |
| [RFC3264] | Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” RFC 3264, June 2002 (TXT). |
| [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 (TXT). |
| [RFC3550] | Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF). |
| [RFC4574] | Levin, O. and G. Camarillo, “The Session Description Protocol (SDP) Label Attribute,” RFC 4574, August 2006 (TXT). |
| [RFC4145] | Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” RFC 4145, September 2005 (TXT). |
| [RFC4579] | Johnston, A. and O. Levin, “Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents,” BCP 119, RFC 4579, August 2006 (TXT). |
| [I-D.ietf-mediactrl-requirements] | Dolly, M. and R. Even, “Media Server Control Protocol Requirements,” draft-ietf-mediactrl-requirements-04 (work in progress), February 2008 (TXT). |
| [I-D.ietf-mediactrl-architecture] | Melanchuk, T., “An Architectural Framework for Media Server Control,” draft-ietf-mediactrl-architecture-04 (work in progress), November 2008 (TXT). |
| [I-D.ietf-mediactrl-sip-control-framework] | Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” draft-ietf-mediactrl-sip-control-framework-11 (work in progress), October 2009 (TXT). |
| [I-D.boulton-mmusic-sdp-control-package-attribute] | Boulton, C., “A Session Description Protocol (SDP) Control Package Attribute,” draft-boulton-mmusic-sdp-control-package-attribute-04 (work in progress), March 2009 (TXT). |
| [I-D.boulton-ivr-control-package] | Boulton, C., Melanchuk, T., and S. McGlashan, “A Basic Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework,” draft-boulton-ivr-control-package-06 (work in progress), February 2008 (TXT). |
| [I-D.boulton-conference-control-package] | Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, “A Conference Control Package for the Media Control Channel Framework,” draft-boulton-conference-control-package-04 (work in progress), February 2008 (TXT). |
| [I-D.boulton-ivr-vxml-control-package] | Boulton, C., Melanchuk, T., and S. McGlashan, “A VoiceXML Control Package for the Media Control Channel Framework,” draft-boulton-ivr-vxml-control-package-04 (work in progress), February 2008 (TXT). |
| [I-D.miniero-bfcp-control-package] | Miniero, L., Romano, S., Even, R., and S. McGlashan, “A Binary Floor Control Protocol (BFCP) Control Package for the Media Control Channel Framework,” draft-miniero-bfcp-control-package-01 (work in progress), July 2008 (TXT). |
| TOC |
| Alessandro Amirante | |
| University of Napoli | |
| Via Claudio 21 | |
| Napoli 80125 | |
| Italy | |
| Email: | alessandro.amirante@unina.it |
| Tobia Castaldi | |
| University of Napoli | |
| Via Claudio 21 | |
| Napoli 80125 | |
| Italy | |
| Email: | tobia.castaldi@unina.it |
| Lorenzo Miniero | |
| University of Napoli | |
| Via Claudio 21 | |
| Napoli 80125 | |
| Italy | |
| Email: | lorenzo.miniero@unina.it |
| Simon Pietro Romano | |
| University of Napoli | |
| Via Claudio 21 | |
| Napoli 80125 | |
| Italy | |
| Email: | spromano@unina.it |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.