Network Working Group A. Amirante Internet-Draft T. Castaldi Expires: May 6, 2008 L. Miniero S P. Romano University of Napoli November 3, 2007 Session Control Protocol (SIP) Control Framework (ESCS/SCFW) Call Flow Examples draft-miniero-mediactrl-escs-00.txt Status of this Memo 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 May 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides with a list of more or less detailed MEDIACTRL Media Server Control Framework [10] 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 Amirante, et al. Expires May 6, 2008 [Page 1] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 protocol researchers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. A Practical Approach . . . . . . . . . . . . . . . . . . . 4 4.1.1. State Diagrams . . . . . . . . . . . . . . . . . . . . 4 4.1.2. Implementation . . . . . . . . . . . . . . . . . . . . 5 5. Control Channel Establishment . . . . . . . . . . . . . . . . 5 5.1. COMEDIA Negotiation . . . . . . . . . . . . . . . . . . . 6 5.2. SYNCH . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Use-case scenarios and examples . . . . . . . . . . . . . . . 9 6.1. Echo Test . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1. Direct Echo Test . . . . . . . . . . . . . . . . . . . 13 6.1.2. Echo Test based on Recording . . . . . . . . . . . . . 16 6.2. Phone Call . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 23 6.2.2. Conference-based Approach . . . . . . . . . . . . . . 23 6.3. Conferencing . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.1. Simple Bridging . . . . . . . . . . . . . . . . . . . 25 6.3.2. Rich Conference Scenario . . . . . . . . . . . . . . . 26 6.3.3. Coaching Scenario . . . . . . . . . . . . . . . . . . 27 6.3.4. Sidebars . . . . . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Amirante, et al. Expires May 6, 2008 [Page 2] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 1. Introduction 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) 2. Conventions 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 [2] and indicate requirement levels for compliant implementations. Besides, note that due to RFC formatting conventions, this document often splits SIP/SDP and ESCS 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. 3. Terminology 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. Application Server: Media Server: Control Channel: Framework Transaction: 4. Overview This document provides with a list of more or less detailed MEDIACTRL Media Server Control Framework [10] call flows. The motivation for Amirante, et al. Expires May 6, 2008 [Page 3] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 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 ESCS 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. 4.1. A Practical Approach TBD. 4.1.1. State Diagrams TBD. (both AS and MS) (Figure not available yet). Figure 1: Application Server ESCS State Diagram Amirante, et al. Expires May 6, 2008 [Page 4] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 (Figure not available yet). Figure 2: Media Server ESCS State Diagram 4.1.2. Implementation TBD. (media- and macro-connections, conferences, plugins) 5. Control Channel Establishment TBD. All figure, single steps analyzed in two paragraphs (COMEDIA, SYNCH). 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 Amirante, et al. Expires May 6, 2008 [Page 5] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 5.1. COMEDIA Negotiation TBD. Specifically addresses the first part of the diagram. 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 \ ;tag=3724Pp001 To: MediaServer Call-ID: 1-3724@as.com Cseq: 1 INVITE Contact: sip:ApplicationServer@as.com:5060 Max-Forwards: 70 Content-Type: application/sdp Content-Length: 158 v=0 o=- 53655765 2353687637 IN IP4 as.com s=- c=IN IP4 as.com Amirante, et al. Expires May 6, 2008 [Page 6] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 t=0 0 m=application 5757 TCP/ESCS a=setup:active a=connection:new 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";tag=07fa6e5b From: "ApplicationServer" \ ;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: To: "MediaServer";tag=07fa6e5b From: "ApplicationServer" \ ;tag=3724Pp001 Call-ID: 1-3724@as.com CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INVITE Content-Type: application/sdp Content-Length: 165 v=0 o=- 53655765 2353687638 IN IP4 ms.org s=MediaCtrl c=IN IP4 ms.org t=0 0 m=application 7575 TCP/ESCS * a=connection:new a=setup:passive 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 \ ;tag=3724Pp001 Amirante, et al. Expires May 6, 2008 [Page 7] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 To: MediaServer ;tag=07fa6e5b Call-ID: 1-3724@as.com Cseq: 1 ACK Contact: sip:ApplicationServer@as.com:5060 Max-Forwards: 70 Content-Length: 0 5.2. SYNCH TBD. Specifically addresses the second part of the diagram. AS MS . . . . | | | 1. SYNCH (Dialog-ID, etc.) | |+++++++++++++++++++++++++++++>>| | |--+ | | | Check SYNCH | |<-+ | 2. 200 OK | |<<+++++++++++++++++++++++++++++| | | . . . . Figure 6: SYNCH: Sequence Diagram 1. AS -> MS (ESCS SYNCH) ------------------------ SCFW 6b8b4567327b SYNCH Dialog-ID: 3724Pp001~1-3724@as.com~07fa6e5b K-alive: 100 Packages: msc-example-pkg/1.0,msc-ivr-basic/1.0 2. AS <- MS (ESCS 200) ---------------------- SCFW 6b8b4567327b 200 K-alive: 100 Amirante, et al. Expires May 6, 2008 [Page 8] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 Packages: msc-example-pkg/1.0,msc-ivr-basic/1.0 Supported: msc-conf-audio/1.0,msc-ivr-vxml/1.0 6. Use-case scenarios and examples 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 8 describes: Amirante, et al. Expires May 6, 2008 [Page 9] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 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 8: 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 [9]: 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 Amirante, et al. Expires May 6, 2008 [Page 10] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 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 [10]. TBD. SIP negotiation -> tags and labels. (Figure not available yet). Figure 9: 3PCC SIP Signaling As a result of the 3PCC negotiation, the following relevant information is retrieved: 1. The 'From' and 'To' tags (1536067209 and 913cd14c respectively); 2. the label associated with the only negotiated media connection, in this case an audio media stream (25547c8). These three identifiers allow the AS and MS to univocally and unambiguosly address to each other the connections associated with the related UAC, specifically: 1. 1536067209~913cd14c, the concatenation of the 'From' and 'To' tags, addresses all the media connections between the MS and the UAC; 2. 1536067209~913cd14c~25547c8, the concatenation of the previous value with the label attribute, addresses only one of the media connections of the UAC session (in this case, the only avaliable media stream). 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). Amirante, et al. Expires May 6, 2008 [Page 11] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 6.1. Echo Test 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 10. +-------+ A (RTP) +--------+ | UAC |=========================>| Media | | A |<=========================| Server | +-------+ A (RTP) +--------+ Figure 10: 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 11: 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 11: 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: 1. a Direct Echo Test approach, where the UAC directly talks to itself; 2. a Recording-based Echo Test approach, where the UAC indirectly talks to itself. Amirante, et al. Expires May 6, 2008 [Page 12] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 6.1.1. Direct Echo Test In the Direct Echo Test approach, the UAC is directly connected to itself. This means that, as depicted in Figure 12, each frame the MS receives from the UAC is sent back to it in real-time. MS +------+ UAC | | o----->>----+--@ | o-----<<----+--@ | | | +------+ Figure 12: 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 13: Amirante, et al. Expires May 6, 2008 [Page 13] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 UAC AS MS | | | | | 1. CONTROL (join UAC to itself) | | |++++++++++++++++++++++++++++++++>>| | | 2. 202 | | |<<++++++++++++++++++++++++++++++++| | | 3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| | | 4. 200 OK |--+ self | |++++++++++++++++++++++++++++++++>>| | join | | 5. REPORT (terminate) |<-+ UAC | |<<++++++++++++++++++++++++++++++++| | | 6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<######################################################>>| | Now the UAC is echoed back everything | |<<######################################################>>| | | | . . . . . . Figure 13: Self Connection: Framework Transaction All the transaction steps have been numbered to ease the understanding and the following of the subsequent explaination lines: o The AS requests the joining of the connection to itself by sending a CONTROL request (1), specifically meant for the conferencing control package (msc-conf-audio/1.0), to the MS: since the connection must be attached to itself, the id1 and id2 attributes are set to the same value, i.e. the connection-id; o The MS takes care of answering with a provisional response (a 202 (2), followed by a REPORT (3) with pending status), and starts evaluating the request; o The AS acks the REPORT (4); o The MS, having checked the validity of the request, actually enforces the joining of the connection to itself; this means that all the frames sent by the UAC are sent back to it; o Subsequently, the MS sends a final REPORT with terminate status (5), which the AS then acks (6), thus ending the transaction. The complete transaction, that is the full bodies of the exchanged messages, is provided in the following lines: Amirante, et al. Expires May 6, 2008 [Page 14] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 1. AS -> MS (ESCS CONTROL) -------------------------- SCFW 74b0dc511949 CONTROL Control-Package: msc-conf-audio Content-Length: 87 2. AS <- MS (ESCS 202) ---------------------- SCFW 74b0dc511949 202 3. AS <- MS (ESCS REPORT pending) --------------------------------- SCFW 74b0dc511949 REPORT Seq: 1 Status: pending Timeout: 10 4. AS -> MS (ESCS 200, ACK to 'REPORT pending') ----------------------------------------------- SCFW 74b0dc511949 200 Seq: 1 5. AS <- MS (ESCS REPORT terminate) ----------------------------------- SCFW 74b0dc511949 REPORT Seq: 2 Status: terminate Timeout: 10 Content-Length: 70 6. AS -> MS (ESCS 200, ACK to 'REPORT terminate') ------------------------------------------------- SCFW 74b0dc511949 200 Seq: 2 Amirante, et al. Expires May 6, 2008 [Page 15] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 6.1.2. Echo Test based on Recording 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 15, 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 15: 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: 1. first, a recording (preceded by an announcement, if requested) must take place; 2. then, a playout of the previously recorded media must occur. This means that two separate transactions need to be invoked. A sequence diagram of a potential multiple transaction is depicted in Figure 16: UAC AS MS | | | | | A1. CONTROL (record for 10s) | | |++++++++++++++++++++++++++++++++>>| | | A2. 202 | | |<<++++++++++++++++++++++++++++++++| | | A3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| prepare & | | A4. 200 OK |--+ start | |++++++++++++++++++++++++++++++++>>| | the Amirante, et al. Expires May 6, 2008 [Page 16] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 | | A5. REPORT (update) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | A6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "This is an echo test: tell something" | |<<########################################################| | | | |########################################################>>| | 10s of audio from the UAC is recorded |--+ save |########################################################>>| | in a | | |<-+ file | | A7. REPORT (terminate) | | |<<++++++++++++++++++++++++++++++++| | Use recorded +--| A8. 200 OK | | file to play | |++++++++++++++++++++++++++++++++>>| | announcement +->| | | | B1. CONTROL (play recorded) | | |++++++++++++++++++++++++++++++++>>| | | B2. 202 | | |<<++++++++++++++++++++++++++++++++| | | B3. REPORT (pending) | | |<<++++++++++++++++++++++++++++++++| prepare & | | B4. 200 OK |--+ start | |++++++++++++++++++++++++++++++++>>| | the | | B5. REPORT (update) |<-+ dialog | |<<++++++++++++++++++++++++++++++++| | | B6. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | |<<########################################################| | "Can you hear me? It's me, UAC, talking" | |<<########################################################| | | | | | B7. REPORT (terminate) | | |<<++++++++++++++++++++++++++++++++| | | B8. 200 OK | | |++++++++++++++++++++++++++++++++>>| | | | . . . . . . Figure 16: Recording-based Echo: Two Framework Transactions As before, all the transaction steps have been numbered to ease the Amirante, et al. Expires May 6, 2008 [Page 17] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 understanding and the following of the subsequent explaination lines. Besides, the two transactions are distinguished by the preceding letter (A=recording, B=playout). o The AS, as a first transaction, invokes a recording on the UAC connection by means of a CONTROL request (A1); the body is for the IVR package (msc-ivr-basic/1.0), and requests the start (dialogstart) of a new recording context (basicivr: promptandrecord); the recording must be preceded by an announcement (prompts), must not last longer than 10s (maxtime), and cannot be interrupted by a DTMF tone (dtmfterm=false); this has only to be done once (iterations), which means that if the recording does not succeed the first time, the transaction must fail; finally, the AS also subscribes to the "dialogexit" event, which means it wants to be informed when the dialog ends for whatever reason; o As seen before, the first responses to the request start flowing: the provisional 202 (A2), the subsequent REPORT pending (A3), and its ack (A4) from the AS; o In the meanwhile, the MS prepares the dialog (e.g. by retrieving the announcement file, for which a HTTP URL is provided, and by checking that the request is well formed) and if all is fine it starts it, notifying the AS about it with a new REPORT (A5) with an update status: the connection is then passed to the IVR package, which records all the incoming frame to a buffer; o The AS acks the latest REPORT (A6), waiting for the result; o Once the recording is over, the MS sends a final REPORT (A7) which contains in its body the path to the recorded file (in this case, a HTTP URL) which can be used by the AS for whatever it needs to; o The AS concludes this first transaction by acking the terminating REPORT (A8). 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: o The AS, as a second transaction, invokes a playout on the UAC connection by means of a new CONTROL request (B1); the body is once againg for the IVR package (msc-ivr-basic/1.0), but this time it requests the start (dialogstart) of a new announcement context (basicivr:playannouncement); the file to be played is the one recorded before (prompts), and has only to be played once (iterations); o Again, the usual provisional 202 (B2), the subsequent REPORT pending (B3), and its ack (B4) from the AS take place; o In the meanwhile, the MS prepares the new dialog and starts it, notifying the AS about it with a new REPORT (B5) with an update status: the connection is then passed to the IVR package, which Amirante, et al. Expires May 6, 2008 [Page 18] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 plays the file on it; o The AS acks the latest REPORT (B6), waiting for the announcement to end; o Once the playout is over, the MS sends a final REPORT (B7) which only contains a notification of the success of the operation; o The AS concludes this second and last transaction by acking the terminating REPORT (B8). As in the previous paragraph, the whole ESCS interaction is provided for a more in depth evaluation of the protocol interaction. A1. AS -> MS (ESCS CONTROL, record) ----------------------------------- SCFW 74b0dc511949 CONTROL Control-Package: msc-ivr-basic Content-Length: 354 A2. AS <- MS (ESCS 202) ----------------------- SCFW 74b0dc511949 202 A3. AS <- MS (ESCS REPORT pending) ---------------------------------- SCFW 74b0dc511949 REPORT Seq: 1 Status: pending Timeout: 10 A4. AS -> MS (ESCS 200, ACK to 'REPORT pending') Amirante, et al. Expires May 6, 2008 [Page 19] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 ------------------------------------------------- SCFW 74b0dc511949 200 Seq: 1 A5. AS <- MS (ESCS REPORT update) --------------------------------- SCFW 74b0dc511949 REPORT Seq: 2 Status: update Timeout: 10 Content-Length: 88 A6. AS -> MS (ESCS 200, ACK to 'REPORT update') ----------------------------------------------- SCFW 74b0dc511949 200 Seq: 2 A7. AS <- MS (ESCS REPORT terminate) ------------------------------------ SCFW 74b0dc511949 REPORT Seq: 3 Status: terminate Timeout: 10 Content-Length: 197 A8. AS <- MS (ESCS REPORT terminate) ------------------------------------ SCFW 74b0dc511949 200 Seq: 3 Amirante, et al. Expires May 6, 2008 [Page 20] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 B1. AS -> MS (ESCS CONTROL, play) --------------------------------- SCFW 238e1f2946e8 CONTROL Control-Package: msc-ivr-basic Content-Length: 319 B2. AS <- MS (ESCS 202) ----------------------- SCFW 238e1f2946e8 202 B3. AS <- MS (ESCS REPORT pending) ---------------------------------- SCFW 238e1f2946e8 REPORT Seq: 1 Status: pending Timeout: 10 B4. AS -> MS (ESCS 200, ACK to 'REPORT pending') ------------------------------------------------ SCFW 238e1f2946e8 200 Seq: 1 B5. AS <- MS (ESCS REPORT update) --------------------------------- SCFW 238e1f2946e8 REPORT Seq: 2 Status: update Timeout: 10 Content-Length: 88 Amirante, et al. Expires May 6, 2008 [Page 21] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 B6. AS -> MS (ESCS 200, ACK to 'REPORT update') ----------------------------------------------- SCFW 238e1f2946e8 200 Seq: 2 B7. AS <- MS (ESCS REPORT terminate) ------------------------------------ SCFW 238e1f2946e8 REPORT Seq: 3 Status: terminate Timeout: 10 Content-Length: 165 B8. AS -> MS (ESCS 200, ACK to 'REPORT terminate') -------------------------------------------------- SCFW 238e1f2946e8 200 Seq: 3 6.2. Phone Call TBD. +-------+ A (RTP) +--------+ A (RTP) +-------+ | UAC |===================>| Media |===================>| UAC | | A |<===================| Server |<===================| B | +-------+ B (RTP) +--------+ B (RTP) +-------+ Figure 18: Phone Call: Media Perspective Amirante, et al. Expires May 6, 2008 [Page 22] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 MS +--------------+ UAC A | | UAC B o----->>----+--x x..+....>>.....o o.....<<....+..x x--+----<<-----o | | +--------------+ Figure 19: Phone Call: UAC Media Leg not attached 6.2.1. Direct Connection TBD. (Easier and more straightforward, but has drawbacks: you can't record the whole conversation, for example, only the single connections, since no mixing is involved. etc...) MS +--------------+ UAC A | | UAC B o----->>----+--+~~~>>~~~+--+---->>-----o o-----<<----+--+~~~<<~~~+--+----<<-----o | | +--------------+ Figure 20: Phone Call: Direct Connection (Figure not available yet). Figure 21: Direct Connection: Framework Transactions 6.2.2. Conference-based Approach TBD. (More complicated and probably eats more resources, but allows more customization on what needs to be done on the conversation, e.g. recording, etc...). Amirante, et al. Expires May 6, 2008 [Page 23] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 MS +---------------+ UAC A | | UAC B o----->>----+--+~~>{#}::>+::+::::>>:::::o o:::::<<:::::::+<::{#}<~~+--+----<<-----o | : | | : | +-------+-------+ : +::::> (conversation.wav) Figure 22: Phone Call: Conference-based Approach (Figure not available yet). Figure 23: Conference-based Approach: Framework Transactions 6.3. Conferencing TBD. (Talk about mixing, the need for custom media delivery, e.g. echo cancellation and media policies like recvonly, resources manipulation, etc...). +-------+ | 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 24: Conference: Media Perspective Amirante, et al. Expires May 6, 2008 [Page 24] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 MS +----------------+ UAC A | | UAC B o----->>----+--x x..+....>>.....o o.....<<.......x x--+----<<-----o | | | | | xx | | |. | +-------++-------+ |. ^v ^v |. oo UAC C Figure 25: Conference: UAC Legs not attached 6.3.1. Simple Bridging TBD. (Only deal with what a mixer basically does: you attach connections to it, and it takes care of transcoding and sending to each user only what it needs/is authorized to receive, e.g. echo cancellation, etc.) MS +-----------------+ UAC A | | UAC B o----->>----+--+~~~>{##}:::>+::+::::>>:::::o o:::::<<:::::::+<:::{##}<~~~+--+----<<-----o | ^: | | |v | | ++ | | |: | +--------++-------+ |: ^v ^v |: oo UAC C Amirante, et al. Expires May 6, 2008 [Page 25] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 Figure 26: Conference: Simple Bridging (Figure not available yet). Figure 27: Simple Bridging: Framework Transactions 6.3.2. Rich Conference Scenario TBD. (Enrich previous scenario: involve IVR, e.g. DTMF collection for PIN-based conference access; recording, e.g. for "state your name" functionality and recording of the whole conference; announcements; etc...). 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 (Figure not available yet). Amirante, et al. Expires May 6, 2008 [Page 26] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 Figure 29: Rich Conference Scenario: Framework Transactions 6.3.3. Coaching Scenario TBD. (Reference RFC4579 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 30: Coaching Scenario: Media Perspective Amirante, et al. Expires May 6, 2008 [Page 27] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 MS +---------------------------+ | | UAC A | | UAC B o.....<<....+..x x--+----<<-----o o----->>----+--x x..+....>>.....o | | | | | | | | | xx | | .| + +------------v^-------------+ v^ .| .| oo UAC C Figure 31: Coaching Scenario: UAC Legs not attached MS +---------------------------+ | +~~~~~~~~~~+ | UAC A | v | | UAC B o-----<<----+--+ +~+~~~~~<~~~~+--+----<<-----o o----->>----+--+~~>[#]<~+ +--+---->>-----o | | : ^ | | +~~~~:~~~>[#]:::::::::+ | | v ^ | | : | | | ::>::++ | | :| + +------------v^-------------+ v^ :| :| oo UAC C Figure 32: Coaching Scenario: UAC Legs mixed and attached Amirante, et al. Expires May 6, 2008 [Page 28] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 (Figure not available yet). Figure 33: Coaching Scenario: Framework Transactions 6.3.4. Sidebars 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 34: Sidebars: Media Perspective (Figure not available yet.) Figure 35: Sidebars: UAC Legs not attached (Figure not available yet.) Figure 36: Sidebars: UAC Legs mixed and attached (Figure not available yet). Figure 37: Sidebars: Framework Transactions Amirante, et al. Expires May 6, 2008 [Page 29] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 7. Security Considerations TBD. (None, since this is informational?) 8. Acknowledgements TBD. 9. References [1] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [4] 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. [5] 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. [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [7] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. [8] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", draft-ietf-mediactrl-requirements-01 (work in progress), October 2007. [9] Melanchuk, T., "An Architectural Framework for Media Server Control", draft-ietf-mediactrl-architecture-00 (work in progress), October 2007. [10] Boulton, C., "A Control Framework for the Session Initiation Protocol (SIP)", draft-ietf-mediactrl-sip-control-framework-00 Amirante, et al. Expires May 6, 2008 [Page 30] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 (work in progress), September 2007. [11] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A Basic Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol (SIP)", draft-boulton-ivr-control-package-04 (work in progress), November 2007. [12] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A Conference Control Package for the Session Initiation Protocol (SIP)", draft-boulton-conference-control-package-03 (work in progress), November 2007. [13] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A VoiceXML Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol (SIP)", draft-boulton-ivr-vxml-control-package-03 (work in progress), November 2007. Authors' Addresses 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 Amirante, et al. Expires May 6, 2008 [Page 31] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy Email: spromano@unina.it Amirante, et al. Expires May 6, 2008 [Page 32] Internet-Draft ESCS/SCFW Basic Call Flow Examples November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Amirante, et al. Expires May 6, 2008 [Page 33]