Subject: Re: [clue] CLUE-enabled call's fallback

From: Robert Hansen <[email-masked]>
Date: Mon, 01 Sep 2014 15:18:28 +0100

Hi Scarlett,

1) Section 4.5.2.3. and 4.5.4.1. address when and how to disable 
non-CLUE-controlled media. There isn't a huge amount of detail (I 
removed all normative language in section 4.5.2.3. as part of the most 
recent draft to make clear it was merely illustrative) but then I'm not 
sure this is something we should be mandating; different implementations 
will likely have different opinions on when non-CLUE-controlled media 
should be disabled (some may never want it, some may want to continue it 
until they have CLUE-controlled media).

2) Section 4.5.2.3. defines when a call falls back from CLUE-enabled to 
non-CLUE enabled, defining it as the first of the options you suggest.

Can you check these sections, and say which ones you think are 
insufficient/should be changed?

Thanks,

Rob

On 30/08/14 03:16, Liuyan (Scarlett) wrote:
>
> Hello,
>
>      I have some issues about CLUE-enabled call’s fallback.
>
>      The signaling draft says:
>
>             A call in which two CLUE-capable devices have successfully 
> negotiated support for a CLUE data channel in SDP.
>
> A CLUE-enabled call is not necessarily immediately able to send 
> CLUE-controlled media; negotiation of the data channel and of the CLUE 
> protocol must complete first
>
>          But the signaling does not say something as below:
>
> 1)When and how to stop the basic media streams?
>
> wait and until the two CLUE-capable device finish the negotiation and 
> use “a=inactive” or set the port number zero related to the basic 
> media streams
>
> 2)When and how to trigger a CLUE-enabled call fall back?
>
> the data channel is explicitly closed by SDP O/A ;
>
> the data channel is closed by SCTP SSN Reset (see the draft 
> draft-ietf-rtcweb-data-protocol-03) ;or
>
> the all CLUE-controlled media streams are removed by SDP O/A
>
>      That’s all and comments welcome.
>
> Best Regards,
>
> Scarlett
>
> ------------------------------------------------------------------------
>
>
> 华为技术有限 公司Huawei Technologies Co., Ltd.
>
>
> Phone: 0086-755-28974289
> Fax:
> Mobile:
> Email: [email-masked]
> 地址：深圳市 龙岗区坂田华为基地 邮编：518129
> Huawei Technologies Co., Ltd.
> Bantian, Longgang District,Shenzhen 518129, P.R.China
> http://www.huawei.com
>
> ------------------------------------------------------------------------
>
> 本邮件及其附件含 有华为公司的保密信息，仅限于发送给上面地址中列出的个 
> 人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散 
> 发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from 
> HUAWEI, which
> is intended only for the person or entity whose address is listed 
> above. Any use of the
> information contained herein in any way (including, but not limited 
> to, total or partial
> disclosure, reproduction, or dissemination) by persons other than the 
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, 
> please notify the sender by
> phone or email immediately and delete it!
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Sep 2014 12:13:04 -0400

Rob, Scarlett,

There is one thing that I am concerned with:

I see an analogy between moving to/from clue-enabled status and moving 
to/from hold status. With hold, if you aren't careful it is possible to 
get into a "stuck on hold" status. Similarly, I think if we aren't 
careful it will be possible to get into a "stuck in clue-disabled" status.

The "stuck on hold" arises when both ends have put the call on hold 
a=inactive has been negotiated. It occurs if one end wants to go off 
hold, but continues to offer a=inactive because it thinks the other end 
wants to be on hold. It is fixed by a policy where each end makes no 
assumptions about what the other end wants in the future when it makes 
offers - offering what it wants for itself. And this needs to be true 
when responding to offerless invites too.

The question is whether we have such issues with clue-enablement.

Consider the following, between Alice and Bob:

- Alice calls Bob, offering CLUE support clue group containing sctp.
- Bob is clue-capable, but can't initially enable it.
   (E.g., cell phone on slow link.) So refuses the SCTP.

The question is what happens subsequently. If Alice has reason to send 
an offer in the future, should she again offer the clue channel? Or 
should she assume that it is up to Bob to take the initiative in 
enabling CLUE? (There may be a cost associated offering the clue 
channel, in ICE, DTLS, etc.)

The safest answer is to say that whenever a clue-capable endpoint sends 
an offer, and is willing/able to be clue-enabled, it should offer the 
SCTP m-line.

We could explore less aggressive approaches. But then we must look very 
carefully - the cases that cause trouble are often subtle, involving 
offerless invites, B2BUAs, etc.

	Thanks,
	Paul

---

From: Robert Hansen <[email-masked]>
Date: Mon, 01 Sep 2014 18:13:06 +0100

Hi Paul,

I'm definitely of the opinion that those who are willing to upgrade a 
call to CLUE-enabled should include a data channel m-line, just like 
coming off hold with media. Section 4.5.4.2. has the following language:

"A CLUE-capable device that receives an initial SDP offer from a 
non-CLUE device SHOULD include a new data channel "m" line and 
corresponding CLUE group in any subsequent offers it sends, to indicate 
that it is CLUE-capable."

I suppose this should be expanded to also cover cases where the call was 
CLUE-enabled but then downgraded, as at the moment it only talks about 
calls that were non-CLUE from the beginning.

Rob

On 01/09/14 17:13, Paul Kyzivat wrote:
> to/from hold status. With hold, if you aren't careful it is possible 
> to get into a "stuck on hold" status. Similarly, I think if we aren't 
> hold, but continues to offer a=inactive because it thinks the other 
> end wants to be on hold. It is fixed by a policy where each end makes 
> no assumptions about what the other end wants in the future when it 
> makes offers - offering what it wants for itself. And this needs to be 
> true when responding to offerless invites too.
>
> The safest answer is to say that whenever a clue-capable endpoint 
> sends an offer, and is willing/able to be clue-enabled, it should 
> offer the SCTP m-line.
>
> We could explore less aggressive approaches. But then we must look 
> very carefully - the cases that cause trouble are often subtle, 
> involving offerless invites, B2BUAs, etc.
>
>     Thanks,
>     Paul
>

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Thu, 4 Sep 2014 07:03:42 +0000

Hi Robert,

         I have read the latest version of draft-ietf-clue-signaling.
         Please see my replies below and thanks.

Best Regards,
Scarlett
From: clue [mailto:[email-masked]] On Behalf Of Robert Hansen
Sent: Monday, September 01, 2014 10:18 PM
To: [email-masked]
Subject: Re: [clue] CLUE-enabled call's fallback

Hi Scarlett,

1) Section 4.5.2.3. and 4.5.4.1. address when and how to disable non-CLUE-controlled media. There isn't a huge amount of detail (I removed all normative language in section 4.5.2.3. as part of the most recent draft to make clear it was merely illustrative) but then I'm not sure this is something we should be mandating; different implementations will likely have different opinions on when non-CLUE-controlled media should be disabled (some may never want it, some may want to continue it until they have CLUE-controlled media).
[Scarlett] The following description answers to the point (i.e. when and how to disable non-CLUE-controlled media), especially the yellow highlight part. Setting the port number associated with the non-CLUE-controlled media zero is to disable the non-CLUE-controlled media. Maybe it needs to slightly be noted that using “a=inactive” does also work.
The section 4.5.4.1 says below:
Once CLUE media has been successfully negotiated devices SHOULD ensure that non-CLUE-controlled media is deactived in cases where it corresponds to the media type of CLUE-controlled media that has been successfully negotiated.  This deactivate may require an additional SDP exchange, or may be incorporated into one that is part of the CLUE negotiation.
The section 7 says below:
Alice now sends 200 OK 3, matching two recvonly m-lines to Bob's new sendonly lines.  She includes their mid values in the grouping attribute to show they are controlled by the CLUE channel.  Alice also now deactivates the initial non-CLUE-controlled media, as bidirectional CLUE-controlled media is now available.

2) Section 4.5.2.3. defines when a call falls back from CLUE-enabled to non-CLUE enabled, defining it as the first of the options you suggest.
[Scarlett] I don't think that the section 4.5.2.3 has specified when a call falls back from CLUE-enabled to non-CLUE enabled. I guess you could mean the green highlight part of the section 4.5.4.3 below.
  If, in an ongoing CLUE-enabled call, an SDP offer-answer negotiation completes in a fashion in which either the CLUE data channel was not successfully negotiated or one side did not include the data channel in a matching CLUE group then CLUE for this channel is disabled.  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.
       I think that it just specifies most scenarios. In here if the SDP offer-answer does not include the data channel in a matching CLUE group, is the DTLS/SCTP association closed ? Actually, when the data channel is devoted more than one data protocols (i.e. CLUE protocol just is one of the data protocols ), maybe using SCTP SSN Reset does work not but remove the DTLS/SCTP association. I think it needs to be noted.
By the way, if an updated SDP offer-answer without all CLUE-controlled media streams, does the  CLUE data channel need exist? Maybe it leaves the implementers to choose. ☺

Can you check these sections, and say which ones you think are insufficient/should be changed?

Thanks,

Rob

     I have some issues about CLUE-enabled call’s fallback.
     The signaling draft says:
            A call in which two CLUE-capable devices have successfully negotiated support for a CLUE data channel in SDP.
A CLUE-enabled call is not necessarily immediately able to send CLUE-controlled media; negotiation of the data channel and of the CLUE protocol must complete first

1)       When and how to stop the basic media streams?
wait and until the two CLUE-capable device finish the negotiation and use “a=inactive” or set the port number zero related to the basic media streams

2)       When and how to trigger a CLUE-enabled call fall back?
the data channel is explicitly closed by SDP O/A ;
the data channel is closed by SCTP SSN Reset (see the draft draft-ietf-rtcweb-data-protocol-03) ;or
the all CLUE-controlled media streams are removed by SDP O/A

Best Regards,
Scarlett

Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com
________________________________
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

clue mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Thu, 4 Sep 2014 07:39:17 +0000

Hi Paul,

	Maybe we ignore the media feature tag indicating support for CLUE.
	Please see my replies below and thanks.

Best Regards
Scarlett

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, September 02, 2014 12:13 AM
> To: [email-masked]
> to/from hold status. With hold, if you aren't careful it is possible to get into a
> "stuck on hold" status. Similarly, I think if we aren't careful it will be possible
> to get into a "stuck in clue-disabled" status.
> 
> a=inactive has been negotiated. It occurs if one end wants to go off hold, but
> continues to offer a=inactive because it thinks the other end wants to be on
> hold. It is fixed by a policy where each end makes no assumptions about
> what the other end wants in the future when it makes offers - offering what
> it wants for itself. And this needs to be true when responding to offerless
> invites too.
> 
[Scarlett] In the above example, you mean that Bob does not include the m line for a clue data channel.
My question is whether Bob includes the "sip.clue" media tag feature or not.
If Bob includes the "sip.clue" media tag feature, Alice can know that Bob supports for CLUE.
Accordingly, Alice can offer a clue data channel again or Bob forwardly offer a clue data channel in the future.
If Bob does not include it, Alice SHOULD not offer a clue data channel again.
> 
> The question is what happens subsequently. If Alice has reason to send an
> offer in the future, should she again offer the clue channel? Or should she
> assume that it is up to Bob to take the initiative in enabling CLUE? (There
> may be a cost associated offering the clue channel, in ICE, DTLS, etc.)
> 
> The safest answer is to say that whenever a clue-capable endpoint sends an
> offer, and is willing/able to be clue-enabled, it should offer the SCTP m-line.
> 
> carefully - the cases that cause trouble are often subtle, involving offerless
> invites, B2BUAs, etc.
> 
> 	Thanks,
> 	Paul
> 
> > recent draft to make clear it was merely illustrative) but then I'm
> > not sure this is something we should be mandating; different
> > implementations will likely have different opinions on when
> > non-CLUE-controlled media should be disabled (some may never want it,
> > some may want to continue it until they have CLUE-controlled media).
> >
> > 2) Section 4.5.2.3. defines when a call falls back from CLUE-enabled
> > to non-CLUE enabled, defining it as the first of the options you suggest.
> >
> >>             A call in which two CLUE-capable devices have
> >> successfully negotiated support for a CLUE data channel in SDP.
> >>
> >> CLUE-controlled media; negotiation of the data channel and of the
> >> CLUE protocol must complete first
> >>
> >> HUAWEI, which is intended only for the person or entity whose address
> >> is listed above. Any use of the information contained herein in any
> >> way (including, but not limited to, total or partial disclosure,
> >> reproduction, or dissemination) by persons other than the intended
> >> please notify the sender by phone or email immediately and delete it!
> >>
> >>
> >>

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Thu, 4 Sep 2014 08:10:56 +0000

Hi Rob,

Best Regards,
Scarlett

> Sent: Tuesday, September 02, 2014 1:13 AM
> To: [email-masked]
> I'm definitely of the opinion that those who are willing to upgrade a call to
> CLUE-enabled should include a data channel m-line, just like coming off hold
> with media. Section 4.5.4.2. has the following language:
> 
> "A CLUE-capable device that receives an initial SDP offer from a non-CLUE
> device SHOULD include a new data channel "m" line and corresponding CLUE
> group in any subsequent offers it sends, to indicate that it is CLUE-capable."
[Scarlett] I am confused about it. The CLUE-capable device can include the media feature tag to indicate support for CLUE in the SIP INVITE and UPDATE requests and responses.
Why does it yet need to include a new data channel "m" line to indicate support for CLUE in any subsequent. 
Maybe you mean in here that it wants to establish a CLUE-enable call or upgrade a CLUE-enable call, not but indicates CLUE-capable.

> >> removed all normative language in section 4.5.2.3. as part of the
> >> most recent draft to make clear it was merely illustrative) but then
> >> I'm not sure this is something we should be mandating; different
> >>> wait and until the two CLUE-capable device finish the negotiation
> >>> and use “a=inactive” or set the port number zero related to the
> >>> basic media streams
> >>>
> >>> This e-mail and its attachments contain confidential information
> >>> from HUAWEI, which is intended only for the person or entity whose
> >>> address is listed above. Any use of the information contained herein
> >>> in any way (including, but not limited to, total or partial

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Sep 2014 15:52:38 -0400

> 	Please see my replies below and thanks.

We must be careful. The feature tag indicates clue-capable, but not 
clue-enabled.

And perhaps even clue-capable isn't quite right - maybe it should 
indicate clue-aware.

The reason I make the distinction is that the device might have all the 
software necessary to do clue, but sometimes it might lack some of the 
resources necessary to do so. And the resource availability might change 
mid-call.

> [Scarlett] In the above example, you mean that Bob does not include the m line for a clue data channel.

Bob is the answerer. He can't omit the m-line.
He either sets port to zero or sets a=inactive.

> If Bob includes the "sip.clue" media tag feature, Alice can know that Bob supports for CLUE.

I think Bob continues to include the feature tag, meaning he is 
"capable" (or "aware") even though he is unwilling to *enable* clue 
right now.

> If Bob does not include it, Alice SHOULD not offer a clue data channel again.

Certainly we could *consider* using the feature tag that way.

	Thanks,
	Paul