Internet DRAFT - draft-kyzivat-clue-telemedical-callflow
draft-kyzivat-clue-telemedical-callflow
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]
