CLUE P. Kyzivat Internet-Draft Huawei Intended status: Informational March 18, 2013 Expires: September 19, 2013 CLUE Telemedical Use Case Callflow draft-kyzivat-clue-telemedical-callflow-02 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 September 19, 2013. Copyright Notice Copyright (c) 2013 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 September 19, 2013 [Page 1] Internet-Draft CLUE Telemedical Use Case Callflow March 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Scenario being illustrated . . . . . . . . . . . . . . . . . 2 3. Proposed Relationship of O/A to CLUE messages . . . . . . . . 2 4. Ladder Diagram . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Message Bodies . . . . . . . . . . . . . . . . . . . . . . . 8 6. TO-DO list . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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 constructed 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. Kyzivat Expires September 19, 2013 [Page 2] Internet-Draft CLUE Telemedical Use Case Callflow March 2013 * 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.) 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. Kyzivat Expires September 19, 2013 [Page 3] Internet-Draft CLUE Telemedical Use Case Callflow March 2013 * 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 | | | |..............| | | | | | | |basic video | | | |..............| | | | | | | |CLUE channel | | | |..............| | | Kyzivat Expires September 19, 2013 [Page 4] Internet-Draft CLUE Telemedical Use Case Callflow March 2013 | | | | |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 | | | |..............| | | | | | | |CLUE channel | | | |..............| | | | | | | |Advertisement | | Kyzivat Expires September 19, 2013 [Page 5] Internet-Draft CLUE Telemedical Use Case Callflow March 2013 | |<-------------| | |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) | | | | | | |Configure | | | |(from surgery)| | | |------------->| | |Configure | | | |(from expert) | | | |<-------------| | | Kyzivat Expires September 19, 2013 [Page 6] Internet-Draft CLUE Telemedical Use Case Callflow March 2013 | | | | |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) | | |<----------------------------| | | | | | |200 OK | | | |---------------------------->| | |Configure | | | |(accept surgery+expert) | Kyzivat Expires September 19, 2013 [Page 7] Internet-Draft CLUE Telemedical Use Case Callflow March 2013 | |<----------------------------| | | | | | |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 TBS 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} 7. Change Log Kyzivat Expires September 19, 2013 [Page 8] Internet-Draft CLUE Telemedical Use Case Callflow March 2013 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. 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. Author's Address Paul H. Kyzivat Huawei Email: pkyzivat@alum.mit.edu Kyzivat Expires September 19, 2013 [Page 9]