CLUE P. Kyzivat Internet-Draft September 20, 2012 Intended status: Informational Expires: March 24, 2013 CLUE Telemedical Use Case Callflow draft-kyzivat-clue-telemedical-callflow-01 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 24, 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 24, 2013 [Page 1] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenario being illustrated . . . . . . . . . . . . . . . . . . 3 3. Proposed Relationship of O/A to CLUE messages . . . . . . . . . 3 4. Ladder Diagram . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Message Bodies . . . . . . . . . . . . . . . . . . . . . . . . 8 6. TO-DO list . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Kyzivat Expires March 24, 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. Proposed Relationship of O/A to CLUE messages The call flow is constructted in accord with this proposed approach for ordering messages. o What media is sent at any time is determined by the most recently received valid config message, constrained by most recent O/A. * When constraint is bandwidth, sender decides what to drop. * A new O/A can make it possible to send more (or less) of the current config. o An O/A should be consistent with the most recent advertisement in each direction. * This gives context to understand why to accept what is offered. (The answerer has no motivation to accept things that aren't.) o A config message always explicitly refers to an advertisement. * It is invalid, and will be rejected, if it doesn't refer to the most recently sent advertisement. (This implies there is a message to NACK a config msg.) o Typically the endpoint that sends the config message makes an offer to enable it. * This end is the first to know what is needed to support the config. * It is also the end that cares. * Can be before or after the config, or both. * Must accommodate the most recent config received from the other side. * But either side may send an O/A at any time for whatever reason, or may send an offerless INVITE to solicit an offer. (This is basic SIP.) Kyzivat Expires March 24, 2013 [Page 3] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 o Require a config message in response to each advertisement. * Ensures no need for continued support of old advertisement. * Until a new config is received, sender of the advertisement may cease sending media that aren't consistent with the new advertisement. o During call major changes requiring O/A will typically happen independently at each endpoint. * But at start of call there will be an exchange of advertisements and configs. * We want to avoid unnecessary O/As in this case. o If receive an advertisement after sending one, before receiving a config: * Should send config before initiating O/A. * If receive offer before sending one, it will typically be sufficient to accommodate your config. * If so, won't need to initiate another O/A. * There may still be glare at SIP level. Use standard SIP remedies for that. * If so, the O/A that glared may not need to be retried. o First O/A of session occurs before any advertisements or configurations. * Must include the CLUE channel. * Everything else is speculative until advertisements are exchanged. * May be best guess at what is needed, or placeholder intended to maximize interop with arbitrary devices. * Before the first config is received, there should be at most a single capture, chosen by sender, per RTP session. 4. Ladder Diagram Surgery MCU Expert Classroom | | | | | | | | | | | | | | | |(1) | | | | |INVITE | | | |(offer basic | | | | audio&video&clue channels) | | |------------->| | | | | | | |200 OK | | | |<-------------| | | | | | | |basic audio | | | |..............| | | Kyzivat Expires March 24, 2013 [Page 4] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 | | | | |basic video | | | |..............| | | | | | | |CLUE channel | | | |..............| | | | | | | |Advertisement | | | |------------->| | | |Advertisement | | | |(Startup capture) | | |<-------------| | | |Configure | | | |("empty" - request nothing) | | |<-------------| | | | | | | |Configure | | | |------------->| | | |INVITE | | | |(to cover both configurations) | |------------->| | | | | | | |200 OK | | | |<-------------| | | | | | | |startup audio | | | |..............| | | | | | | |startup video | | | |..............| | | | | | | |CLUE channel | | | |..............| | | | | | | | | | |(2) | | | | | |INVITE | | | |(offer basic | | | | audio&video&clue channels) | | |<-------------| | | | | | | |200 OK | | | |------------->| | | | | | | |basic audio | | | |..............| | | | | | | |basic video | | Kyzivat Expires March 24, 2013 [Page 5] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 | |..............| | | | | | | |CLUE channel | | | |..............| | | | | | | |Advertisement | | | |<-------------| | |Advertisement | | | |(from expert) | | | |<-------------| | | | |Advertisement | | | |(from surgery)| | | |------------->| | |INVITE | | | |(prep for config) | | |------------->| | | | |INVITE | | | |(prep for config) | | |<-------------| | | | | | |200 OK | | | |<-------------| | | | | | | | |200 OK | | | |------------->| | |Configure | | | |(accept | | | | expert input)| | | |------------->| | | | |Configure | | | |(accept input | | | | from surgery)| | | |<-------------| | | | | | |video from expert | | |..............| | | | | | | |audio from expert | | |..............| | | | | | | | |video from surgery | | |..............| | | | | | | |audio from surgery | | |..............| | |(with luck maybe we don't need | | another OA for the reverse flow) | | | | | Kyzivat Expires March 24, 2013 [Page 6] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 | |Configure | | | |(from surgery)| | | |------------->| | |Configure | | | |(from expert) | | | |<-------------| | | | | | | |2-way video | | | |..............| | | | | | | |2-way audio | | | |..............| | | | | | | | |2-way video | | | |..............| | | | | | | |2-way audio | | | |..............| | | | | | | | | |(3) | | | | | |INVITE | | | |(offer basic | | | | audio&video&clue channels) | | |<----------------------------| | | | | | |200 OK | | | |---------------------------->| | | | | | |basic audio | | | |.............................| | | | | | |basic video | | | |.............................| | | | | | |CLUE channel | | | |.............................| | | | | | |Advertisement | | | |<----------------------------| | |Advertisement | | | |(surgery+expert) | | |---------------------------->| | |Configure | | | |("empty" - request nothing) | | |---------------------------->| | |INVITE | | | |(prep for config) | Kyzivat Expires March 24, 2013 [Page 7] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 | |<----------------------------| | | | | | |200 OK | | | |---------------------------->| | |Configure | | | |(accept surgery+expert) | | |<----------------------------| | | | | | |video from surgery & expert | | |.............................| | | | | | |audio from surgery & expert | | |.............................| | | | | | | | |(4) | | | | |Surgery & expert don't see classroom | |for now assume MCU enforces this by | |not advertising classroom to them. | | | | | | | | | | | | | | | | | 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. 5. Message Bodies 6. TO-DO list o Reference [I-D.westerlund-avtcore-max-ssrc] in the initial offer proposing how many RTP streams can be sent and received simultaneously in the offered RTP session. For example the offerer can send up to 6 RTP streams and receive up to 4. This will help with providing a better advertisements from both sides: m=video 49200 RTP/AVP 99 a=rtpmap:99 H264/90000 a=max-send-ssrc:{*:6} a=max-recv-ssrc:{*:4} Kyzivat Expires March 24, 2013 [Page 8] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 7. Change Log 1. Captured suggestion from Roni in a TODO list for later. And made a number of adjustments/cleanups to the diagram. Incorporated a comment from Espen for the MCU to send "empty" configuration initially, and about a missing config message. Reworked to incorporate and follow the approach I proposed on the first day of the interim. 8. Security Considerations TBS 9. IANA Considerations This specification ha no IANA considerations 10. References 10.1. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [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. [I-D.westerlund-avtcore-max-ssrc] Westerlund, M., Burman, B., and F. Jansson, "Multiple Synchronization sources (SSRC) in RTP Session Signaling", draft-westerlund-avtcore-max-ssrc-02 (work in progress), July 2012. 10.2. Informative References Kyzivat Expires March 24, 2013 [Page 9] Internet-Draft CLUE Telemedical Use Case Callflow September 2012 Author's Address Paul H. Kyzivat Email: pkyzivat@alum.mit.edu Kyzivat Expires March 24, 2013 [Page 10]