CLUE P. Kyzivat Internet-Draft September 11, 2012 Intended status: Informational Expires: March 15, 2013 CLUE Telemedical Use Case Callflow draft-kyzivat-clue-telemedical-callflow-00 Abstract This is the beginning of an example call flow for an instantiation of the use case described in the telemedical use case [I-D.xiao-clue-telemedical-use-case]. More detail will be added later. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 15, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kyzivat Expires March 15, 2013 [Page 1] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenario being illustrated . . . . . . . . . . . . . . . . . . 3 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Ladder Diagram . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Message Bodies . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Kyzivat Expires March 15, 2013 [Page 2] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 1. Introduction This is a first cut at the call flow. So far it only includes the ladder diagram showing the exchange of SIP and CLUE messages. The content of those messages will be added later. Before doing that it will be useful to agree on at least one acceptable sequence of messages to realize this use case. 2. Scenario being illustrated The case considered here consists of one surgery room, one remote expert, and one remote classroom, connected by an MCU. The classroom connects first and waits until the surgery begins. The surgery room connects second. At that point the classroom and surgery are joined by the MCU. The expert joins last. 3. Assumptions I have made an assumption here that the SDP in the initial offer on each leg is "vanilla" audio/video plus an m-line for the CLUE signaling channel. Once it is verified that both sides support CLUE, and advertisements and configurations have been exchanged, another offer/answer exchange is done to accommodate what has been configured. There are other strategies that could be used here: o The initial O/A could have a more expansive SDP that is sufficient to accommodate common CLUE sessions. If to, then another O/A may not be needed after configurations are exchanged. o There could be a requirement that an advertisement cannot be sent until SDP has been negotiated that is sufficient for any configurations of that advertisement that might be chosen. o There could be a requirement that a configuration cannot be requested until SDP has been negotiated that is sufficient to accommodate that configuration as well as the configuration in effect in the other direction. 4. Ladder Diagram Surgery MCU Expert Classroom | | | | | | | | | |INVITE | | | |(offer basic audio+video+clue channel) | |<----------------------------| Kyzivat Expires March 15, 2013 [Page 3] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 | | | | | |200 OK | | | |---------------------------->| | | | | | |basic audio | | | |.............................| | | | | | |basic video | | | |.............................| | | | | | |CLUE channel | | | |.............................| | | | | | |Advertisement | | | |<----------------------------| | |(Defer config & advertisement| | | until another endpoint arrives) | | | | |INVITE | | | |(offer basic audio+video+clue channel) | |------------->| | | | | | | |200 OK | | | |<-------------| | | | | | | |basic audio | | | |..............| | | | | | | |basic video | | | |..............| | | | | | | |CLUE channel | | | |..............| | | | | | | |Advertisement | | | |------------->| | | | | | | | |(These advertisements may be concurrent) | | | | |Advertisement | | | |(based on adv from classroom)| | |<-------------| | | |Configure | | | |(without regard for what will be needed???) | |<-------------| | | | | | | |Configure | | | |------------->| | | Kyzivat Expires March 15, 2013 [Page 4] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 |INVITE | | | |(to cover both configurations) | |------------->| | | | | | | |200 OK | | | |<-------------| | | | | | | |clue audio | | | |..............| | | | | | | |clue video | | | |..............| | | | | | | |CLUE channel | | | |..............| | | | |Configure | | | |(based on conf from surgery) | | |---------------------------->| | |Advertisement | | | |(based on adv from surgery) | | |---------------------------->| | | | | | |Configure | | | |<----------------------------| | |INVITE | | | |(to cover both configurations) | |<----------------------------| | | | | | |200 OK | | | |---------------------------->| | | | | | |clue audio | | | |.............................| | | | | | |clue video | | | |.............................| | | | | | |CLUE channel | | | |.............................| | |INVITE | | | |(offer basic audio+video+clue channel) | |<-------------| | | | | | | |200 OK | | | |------------->| | | | | | | |basic audio | | | |..............| | Kyzivat Expires March 15, 2013 [Page 5] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 | | | | | |basic video | | | |..............| | | | | | | |CLUE channel | | | |..............| | | | | | | |Advertisement | | | |<-------------| | | | |(These advertisements may | | | be concurrent) | | | | | | | | | |Advertisement | | | |------------->| | | | | | | | |(Defer config till get request) | | | | |Advertisement | | | |(updated with expert info) | | |<-------------| | | |Configure | | | |(accept expert input) | | |------------->| | | | |Configure | | | |(based on surgery config) | | |------------->| | | | | | |(assume new offer-answer not needed) | | | | | | |INVITE | | | |(to cover both configurations) | |<-------------| | | | | | | |200 OK | | | |------------->| | | | | | | |clue audio | | | |..............| | | | | | | |clue video | | | |..............| | | | | | | |CLUE channel | | | |..............| | | | | | | | | | | | | | Kyzivat Expires March 15, 2013 [Page 6] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 4.1. Comments There are some issues with the ladder diagram above due to the tool I've used to generate it. The CLUE messages are shown with "--->" rather than "...>" because the tool can't do the latter. There is an issue with SDP O/A that I have never seen discussed: when you send a new O/A that updates a session, how do you know when those changes have taken effect? How long must you continue to support media according to the prior negotiated SDP? With CLUE we have enlarged that problem: o Must an Advertisement be consistent with the currently negotiated SDP? o Must a Configuration message be consistent with the currently negotiated SDP? o Which side is responsible for initiating a new O/A when the old one is insufficient to support the advertisement(s) and configuration(s)? o How long must an old advertisement be supported after a new one is sent? What if the you never get a Configure message back in response to the new advertisement because the other end prefers to keep receiving what it currently getting. (Does that mean that a new advertisement must always encompass any configurations currently in effect?) o Can a Configure message reference an Advertisement other than the most recently sent one? Is it permissible to reject such a request? 5. Message Bodies TBS 6. Security Considerations 7. IANA Considerations This specification ha no IANA considerations 8. References 8.1. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Kyzivat Expires March 15, 2013 [Page 7] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [I-D.xiao-clue-telemedical-use-case] Xiao, L. and R. Even, "Use Case for Telemedical with Multi-streams", draft-xiao-clue-telemedical-use-case-00 (work in progress), July 2012. 8.2. Informative References Author's Address Paul H. Kyzivat Email: pkyzivat@alum.mit.edu Kyzivat Expires March 15, 2013 [Page 8]