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

From: "Rob Hansen (rohanse2)" <[email-masked]>
Date: Tue, 15 Mar 2016 04:22:35 +0000

Hi Christian,

Have just uploaded a new draft, incorporating your suggestions - thank you for providing them. On the section on disabling CLUE mid-call it is now explicit about the procedure for doing so. It also covers what to do if the far end does so, and clarifies that if the data channel fails or is closed without a corresponding SDP negotiation to disable it CLUE-controlled media should continue to flow.

Rob

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 22 January 2016 05:08
To: [email-masked]
Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt

Hello Rob,

Thanks for the update. A couple of comments:

cl. 4.5.2.2 adds "lines for compatible encodings" - is compatible the right term here? Isn't it more "accepted encodings"?

cl. 4.5.4.3: I've made a comment a couple of times now about the need to mention SCTP reset for disabling CLUE mid call but it appears to be missed. Both draft-ietf-clue-datachannel (cl.3.2.7) and draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) both mention that an SCTP SSN reset has to be performed. 
draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) mentions that its protocol specific whether this is announced by SDP.

So I would propose to word the first paragraph of cl.4.5.4.3 differently:

"If order to close a CLUE data channel in an ongoing CLUE-enabled call, an endpoint shall follow the procedures for closing a data channel defined in clause 5.2.4 [draft-ietf-mmusic-data-channel-sdpneg] by sending a new SDP offer/answer exchange and subsequent SCTP SSN reset for the CLUE channel.

In the event that this occurs, CLUE is no longer enabled and sending of 
all   CLUE-controlled media associated with the corresponding CLUE group 
MUST stop.  If the data channel is still present but not included in the CLUE group semantic CLUE protocol messages MUST no longer be sent."

Regards, Christian

On 22/01/2016 3:53 AM, Robert Hansen wrote:
> Hi all, apologies that this took longer than intended to revise and 
> check.
>
> Thanks to all the reviewers - almost all suggestions were 
> incorporated, usually as-is when suggested text was provided.
>
> * Removed the entire 'Media line directionality' section as a 
> discussion of the pros/cons of using bidirectional vs unidirectional 
> schemes wasn't suitable for a finalised version. The unidirectionality 
> requirement is covered normatively in an earlier section.
>
> * BUNDLE no longer includes an address synchronisation step so the 
> suggestion to wait until that done has been replaced with some general 
> language about following any negotiated extensions.
>
> * Added OPTIONS negotiation to the example flow, and revised the flow 
> to ensure it matched protocol document.
>
> * Section on not sending CLUE control media until CLUE negotiation 
> completes narrowed to notify that only RTP should not be sent until 
> negotiation completes and add RTCP to the list of things that should 
> be sent as normal, in line with a=inactive.
>
> *  Make explicit that m=recvonly lines don't need to have a label, as 
> only m=sendonly lines are referenced by CLUE protocol messages.
>
> * Fix formatting of IANA sections.  Improve syntax of feature tag 
> section in line with Paul's suggestions.  Definition of feature tag 
> narrowed to be multiple media lines 'negotiated via CLUE protocol'
> rather than more generic 'multiple media lines'.
>
> One thing that Paul brought up was that in 5.1 "Later there are 
> references to named states and transitions in the clue protocol. These 
> don't seem to be consistent with the current state machine 
> definitions" - I've checked and to me they seem to be consistent with 
> the state machines in the protocol document.
>
> Rob
>
> On 21/01/16 16:29, [email-masked] wrote:
>> 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 Working Group of the IETF.
>>
>>          Title           : CLUE Signaling
>>          Authors         : Paul Kyzivat
>>                            Lennard Xiao
>>                            Christian Groves
>>                            Robert Hansen
>>     Filename        : draft-ietf-clue-signaling-07.txt
>>     Pages           : 36
>>     Date            : 2016-01-21
>>
>> Abstract:
>>     This document specifies how CLUE-specific signaling such as the CLUE
>>     protocol [I-D.ietf-clue-protocol] and the CLUE data channel
>>     [I-D.ietf-clue-datachannel] are used 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's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-clue-signaling-07
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-07
>>
>>
>> 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/
>>
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

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

---

From: "Rob Hansen (rohanse2)" <[email-masked]>
Date: Tue, 15 Mar 2016 04:34:39 +0000

Hi Paul, have just uploaded a new draft incorporating your review - thank you for the attention to detail.

I did indeed manage to miss your section 8 comments on the previous revision - apologies for that. I worked on the revision offline and pulled what I thought was all the relevant emails with review comments but missed that one, so only included the basilar comments that were discussed further in a subsequent email. 

> About the flow: The call flow shows INVITE 2 followed by a clue 
configure and response followed by 200 ok. This certainly encourages the 
inference that there is a dependency on doing the configure before 
sending the invite response. That is contrary to protocol requirements. 
(And the same holds for INVITE 3.)

Agreed -  have rearranged messages and changed text to make clear that there should be no such dependency and that the SIP 200 OK should be send independently of the CLUE Configure message.

> Also, there should be responses for the Advertisements.

Added.

> This shows Alice's advertisement going first, and Bob's advertisement 
being sent after receiving Alice's. This is of course possible, but it 
may suggest that there is a cause/effect relationship. It would be good 
to at least mention that the decisions are independent. It might make 
sense to show the messages crossing on the wire, making it clear that 
they are independent.

Have added text to the effect that both sides send their messages independently, and adding the ACKs after both are sent helps clarify this.

> you get to the point where Alice sends INVITE 2. At this point, 
both Alice and Bob need to update the SDP. There is potential for a race 
condition for who goes first. Why is it that Alice goes first, and Bob 
doesn't try before receiving Alice's reINVITE? It would be good to 
explain this. (Or simply state that this just of of several ways this 
might play out depending on timing.)

Have kept Alice sending her INVITE first in the example to reduce complexity but have added a paragraph pointing out that this isn't the only way to do it and that often both sides will send their INVITEs and resolve this via glare resolution.

> I think it would be good to show the 200 for INVITE 2 prior to sending 
the Configure. This will make clear that the sip signaling not be 
delayed. Or just mention that they are both sent nearly concurrently.

I've kept the Configure message first as we do earlier say to do CLUE before SDP, but have made clear in the text that they are sent independently and at pretty much the same time; both are shown as sent before the far end sends an ACK or CONFIGURE RESPONSE

> Finally, there should probably be another O/A at the end to completely 
disable the non-clue media. (Maybe it would be interesting to show that 
one end keeps the non-clue media until the clue media is flowing, while 
the other end stops receiving the non-clue media as soon as it confirms 
this will be a clue call.)

The SIP OK 3 from Alice disables the non-clue media so I don't think there's a need for an additional O/A. 

Thanks both for the original review and pointing out I'd missed making some of the revisions.

Rob

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 25 January 2016 20:43
To: [email-masked]
Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt

On 1/21/16 11:53 AM, Robert Hansen wrote:
> Hi all, apologies that this took longer than intended to revise and check.
>

This generally looks good. I found a few nits while reading:

* Section 4.5.3.1:

s/"m=" line to send or receive/"m=" lines to send or receive/

* Section 4.5.4.3:

s/distinct to/distinct from/

(This isn't new, I missed it previously.) As written I think it means the opposite of what it intends.

* Section 8:

Did you attempt to address my comments in:

http://mailarchive.ietf.org/arch/msg/clue/gYAy7v42JN8uxFz53qxBVki7OBY

I see a few of the editorial ones addressed, but not the substantial ones. For the most part the meaty ones still apply.

	Thanks,
	Paul

> don't seem to be consistent with the current state machine definitions"
> - I've checked and to me they seem to be consistent with the state 
> machines in the protocol document.
>
> Rob
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Mar 2016 11:17:30 -0400

> Hi Paul, have just uploaded a new draft incorporating your review - thank you for the attention to detail.

Based on a review of the diffs, this seems good to me.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Mar 2016 11:20:02 -0400

> Have just uploaded a new draft, incorporating your suggestions - thank you for providing them. On the section on disabling CLUE mid-call it is now explicit about the procedure for doing so. It also…

In section 4.5.5.3:

    If, during an ongoing CLUE-enabled call a device wishes to disable
    CLUE, it can do so by following the procedures for closing a data
    channel defined in Section 5.2.4 of
    [I-D.ietf-mmusic-data-channel-sdpneg]: sending a new SDP offer/answer
    exchange and subsequent SCTP SSN reset for the CLUE channel.  It MUST
    also remove the "mid" for the data channel from the CLUE group.

Shouldn't the entire clue group be removed???

Otherwise this seems good.

	Thanks,
	Paul

---

From: Robert Hansen <[email-masked]>
Date: Thu, 17 Mar 2016 18:48:48 +0000

Hi Paul,

I did originally have a 'MUST also remove the CLUE group' bit, but then 
I thought that there might be usecases where people want to keep the 
CLUE-controlled media m-lines negotiated, though. If they remove the 
CLUE group then they have to zero all the CLUE-controlled m-lines (since 
without a CLUE group these then just become normal m-lines).

Maybe that's a contrived use-case though, and we could have a 'MUST 
remove the CLUE group and SHOULD 0 all CLUE-controlled m-lines' type bit 
at the end.

Rob

On 15/03/16 15:20, Paul Kyzivat wrote:
>> Have just uploaded a new draft, incorporating your suggestions - 
>> thank you for providing them. On the section on disabling CLUE 
>> mid-call it is now explicit about the procedure for doing so. It also 
>> covers what to do if the far end does so, and clarifies that if the 
>> data channel fails or is closed without a corresponding SDP 
>> negotiation to disable it CLUE-controlled media should continue to flow.
>
> In section 4.5.5.3:
>
>> cl. 4.5.2.2 adds "lines for compatible encodings" - is compatible the 
>> right term here? Isn't it more "accepted encodings"?
>>
>> cl. 4.5.4.3: I've made a comment a couple of times now about the need 
>> to mention SCTP reset for disabling CLUE mid call but it appears to 
>> be missed. Both draft-ietf-clue-datachannel (cl.3.2.7) and 
>> draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) both mention that an 
>> SCTP SSN reset has to be performed.
>> draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) mentions that its 
>> protocol specific whether this is announced by SDP.
>>
>> "If order to close a CLUE data channel in an ongoing CLUE-enabled 
>> call, an endpoint shall follow the procedures for closing a data 
>> channel defined in clause 5.2.4 
>> [draft-ietf-mmusic-data-channel-sdpneg] by sending a new SDP 
>> offer/answer exchange and subsequent SCTP SSN reset for the CLUE 
>> channel.
>>
>> MUST stop.  If the data channel is still present but not included in 
>> the CLUE group semantic CLUE protocol messages MUST no longer be sent."
>>
>> Regards, Christian
>>
>>
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Mar 2016 16:01:05 -0400

> remove the CLUE group and SHOULD 0 all CLUE-controlled m-lines' type bit

ISTM is is certainly *possible* to keep the (previously) clue-controlled 
media lines after terminating the clue session. At that point I think 
they must cease to be clue-controlled. So the clue group becomes 
meaningless at that point.

If we want to ascribe some particular meaning to media lines in a clue 
group without clue channel, then we need to specify what that meaning is.

Absent that, ISTM the proper thing to do is to remove the clue group. 
Then the previously clue-controlled media should be terminated (port=0), 
or else retained as non-clue-controlled media. If retained, then the 
significance of them becomes a private matter.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Sun, 20 Mar 2016 13:40:27 +1100

On 18/03/2016 7:01 AM, Paul Kyzivat wrote:
> ISTM is is certainly *possible* to keep the (previously) 
> clue-controlled media lines after terminating the clue session. At 
> that point I think they must cease to be clue-controlled. So the clue 
> group becomes meaningless at that point.
>
> Then the previously clue-controlled media should be terminated 
> (port=0), or else retained as non-clue-controlled media. If retained, 
> then the significance of them becomes a private matter.
>
>     Thanks,
>     Paul
>
[CNG] Seems a reasonable approach.

Regards, Christian