CLUE Telemedical Use Case Callflow
draft-kyzivat-clue-telemedical-callflow-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Paul Kyzivat | ||
| Last updated | 2012-09-10 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kyzivat-clue-telemedical-callflow-00
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]