CLUE Telemedical Use Case Callflow
Huaweipkyzivat@alum.mit.edu
RAI
CLUE
This is the beginning of an example call flow for an instantiation of the use case
described in the telemedical use case.
More detail will be added later.
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.
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.
The call flow is constructed in accord with this proposed approach for ordering messages.
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.
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.)
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.)
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.)
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.
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.
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.
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.
| | |
| | | |
|200 OK | | |
|<-------------| | |
| | | |
|basic audio | | |
|..............| | |
| | | |
|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 | |
| |..............| |
| | | |
| |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) |
| | | |
| |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) |
| |<----------------------------|
| | | |
| |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. |
| | | |
| | | |
| | | |
| | | |
]]>
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.
TBS
Reference 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}
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.
TBS
This specification ha no IANA considerations