Subject: [clue] I-D Action: draft-ietf-clue-signaling-13.txt

From: [email-masked]
Date: Mon, 20 Nov 2017 06:11:10 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the ControLling mUltiple streams for tElepresence WG of the IETF.

        Title           : Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)
        Authors         : Robert Hansen
                          Paul Kyzivat
                          Lennard Xiao
                          Christian Groves
	Filename        : draft-ietf-clue-signaling-13.txt
	Pages           : 41
	Date            : 2017-11-20

Abstract:
   This document specifies how CLUE-specific signaling such as the CLUE
   protocol and the CLUE data channel are used in conjunction with each
   other and with existing signaling mechanisms such as SIP and SDP to
   produce a telepresence call.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-clue-signaling-13
https://datatracker.ietf.org/doc/html/draft-ietf-clue-signaling-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Rob Hansen (rohanse2)" <[email-masked]>
Date: Mon, 20 Nov 2017 14:27:24 +0000

Hi all, was hoping to get this out last week, but inevitably a few things did catch fire. 

Not a huge number of changes since -12; changelog is at https://tools.ietf.org/html/draft-ietf-clue-signaling-13#section-13

The major change is adding a section on the actions to take in the event of a failure of the protocol (either due to loss of the transport or an error on the channel). Originally I thought this should go in the protocol document, but since it involves interactions between the protocol, SIP and media I figure the signalling document is actually probably a better place for it. It can be found at https://tools.ietf.org/html/draft-ietf-clue-signaling-13#section-4.5.4.4 , and currently reads:

"
4.5.4.4.  CLUE protocol failure mid-call

   In contrast to the specific disablement of the use of CLUE described
   above, the CLUE channel may fail unexpectedly.  Two circumstances
   where this can occur are:

   o  The CLUE data channel terminates, either gracefully or
      ungracefully, without any corresponding SDP renegotiation.

   o  The CLUE protocol enters an unrecoverable error state as defined
      in Section 6. of [I-D.ietf-clue-protocol], either the 'MP-
      TERMINATED' state for the Media Provider or 'MC-TERMINATED' for
      the Media Consumer.

   In this circumstance implementations MUST continue to transmit and
   receive CLUE-controlled media on the basis of the last negotiated
   CLUE messages, until the CLUE protocol is disabled mid-call by an SDP
   exchange as defined in Section 4.5.4.3.  Implementations MAY choose
   to send such an SDP request to disable CLUE immediately or MAY
   continue on in a call-preservation mode.
"

Hopefully this reflects people's understanding of what should be done here. Not sure if the final sentence is strictly necessary, but figured it was more helpful to state it explicitly.

Rob

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 20 November 2017 14:11
To: [email-masked]
Cc: [email-masked]
Subject: [clue] I-D Action: draft-ietf-clue-signaling-13.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Nov 2017 12:49:58 -0500

> Hopefully this reflects people's understanding of what should be done here. Not sure if the final sentence is strictly necessary, but figured it was more helpful to state it explicitly.

This sounds just right to me.

	Thanks,
	Paul