Subject: [clue] Some thoughts on protocol and signalling drafts

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 22 Jan 2015 13:18:36 +0100

Dear all,

while working on the updated version of the protocol draft, we ended up doing a review of the signaling draft, which is, as you all know, strictly coupled to our protocol document.
Based on this, I would like to share with you a couple of thoughts/doubts we still have on CLUE as a whole. Please bear with me if I bring back to the fore issues we have already discussed in the past, which are listed below.

1. CLUE and SIP

Do we really need to state that SIP is mandatory for CLUE? I mean, our feeling is that the current specification of CLUE actually gives for granted that we use a mix of SDP and CLUE-level information in order to properly setup (and modify) a CLUE-enabled session. Now, SDP can be sent back and forth between two CLUE-enabled end-points in a number of different ways, SIP being just one of them. Clearly enough, I am thinking of the WebRTC scenario, whereby we might initially leverage a signaling server in order to exchange SDPs between Producer and Consumer. In that case, the very first SIP session setup (which is needed in order to create the CLUE data channel) might be replaced by a "signaling-server-mediated" WebRTC session negotiation. Once the session is up and running, further SDP objects (used to negotiate CLUE-controlled media) might be transferred directly across the CLUE channel, in much the same way as it happens for CLUE protocol messages, with no further need for a third-party mediator.
I am not stating here that we have to bend towards this second approach; though, I do think we might somehow relax the SIP requirement and allow for more than a single alternative in CLUE. What’s your feeling about this?

2. CLUE session recovery after a crash of the CLUE channel

As per our discussions at the last IETF, the group seemed to agree on the fact that in the event of a channel error during normal CLUE operation, the media that were being CLUE-controlled do not have to be torn down and can instead keep on going (even in the absence of CLUE control). If we go to the CLUE participant’s state machine (section 6 of the protocol draft) this means that we do not have to release resources in this case, but simply move to the “Idle” state and start the CLUE channel creation phase once again. In such a situation, we would find ourselves in the need of: (i) re-establishing the CLUE channel; (ii) adding the already available media (those which were CLUE-controlled before channel crash) to the newly provided CLUE channel.

We were wondering if this can be achieved with the following sequence of exchanges:

a) I send a first SDP containing both the (non-CLUE-controlled) available media and the m-line associated with the new CLUE channel I want to setup. As an example, the excerpt below assumes one video stream (with mid=2) is already available when I start re-negotiating the  CLUE channel (whose mid is 5).

...
a=group:CLUE 5
...
m=video 6002 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:2
...
m=application 6100 DTLS/SCTP webrtc-datachannel
a=fmtp:webrtc-datachannel max-message-size=100000
a=sctp-port 5000
a=mid:5

b) Once done with channel setup, I send a new SDP which simply adds the video stream with mid=2 to the CLUE group, in order to indicate that the stream in question is going to be CLUE-controlled once again:

...
a=group:CLUE 5 2
...
m=video 6002 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:2
...
m=application 6100 DTLS/SCTP webrtc-datachannel
a=fmtp:webrtc-datachannel max-message-size=100000
a=sctp-port 5000
a=mid:5

Thanks in advance for your comments and suggestions,

Simon

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Christian Groves <[email-masked]>
Date: Fri, 23 Jan 2015 09:33:16 +1100

Hello Simon,

Please see my replies below.

Regards, Christian

On 22/01/2015 11:18 PM, Simon Pietro Romano wrote:
> Dear all,
>
> while working on the updated version of the protocol draft, we ended 
> up doing a review of the signaling draft, which is, as you all know, 
> strictly coupled to our protocol document.
> Based on this, I would like to share with you a couple of 
> thoughts/doubts we still have on CLUE as a whole. Please bear with me 
> if I bring back to the fore issues we have already discussed in the 
> past, which are listed below.
>
> 1. CLUE and SIP
>
> Do we really need to state that SIP is mandatory for CLUE? I mean, our 
> feeling is that the current specification of CLUE actually gives for 
> granted that we use a mix of SDP and CLUE-level information in order 
> to properly setup (and modify) a CLUE-enabled session. Now, SDP can be 
> sent back and forth between two CLUE-enabled end-points in a number of 
> different ways, SIP being just one of them. Clearly enough, I am 
> thinking of the WebRTC scenario, whereby we might initially leverage a 
> signaling server in order to exchange SDPs between Producer and 
> Consumer. In that case, the very first SIP session setup (which is 
> needed in order to create the CLUE data channel) might be replaced by 
> a "signaling-server-mediated" WebRTC session negotiation. Once the 
> session is up and running, further SDP objects (used to negotiate 
> CLUE-controlled media) might be transferred directly across the CLUE 
> channel, in much the same way as it happens for CLUE protocol 
> messages, with no further need for a third-party mediator.
> I am not stating here that we have to bend towards this second 
> approach; though, I do think we might somehow relax the SIP 
> requirement and allow for more than a single alternative in CLUE. 
> What’s your feeling about this?

[CNG] I think the argument was that the IETF defines RFCs to support 
IETF protocols i.e. SIP. So if you use CLUE outside of IETF you can 
ignore the requirement. e.g. H.323 is being updated by in ITU-T SG16 
Question 5 to also support CLUE. My opinion is that in the CLUE WG we 
should focus on SIP but if someone wants to also use CLUE with other 
protocols then that's good for CLUE. So I'm happy to relax the statement.

> As per our discussions at the last IETF, the group seemed to agree on 
> the fact that in the event of a channel error during normal CLUE 
> operation, the media that were being CLUE-controlled do not have to be 
> torn down and can instead keep on going (even in the absence of CLUE 
> control). If we go to the CLUE participant’s state machine (section 6 
> of the protocol draft) this means that we do not have to release 
> resources in this case, but simply move to the “Idle” state and start 
> the CLUE channel creation phase once again. In such a situation, we 
> would find ourselves in the need of: (i) re-establishing the CLUE 
> channel; (ii) adding the already available media (those which were 
> CLUE-controlled before channel crash) to the newly provided CLUE channel.

[CNG] Wouldn't this depend on what layer the CLUE channel error occurs? 
e.g. if CLUE crashes then you simply resend OPTIONs etc. on the existing 
SCTP stream. If the SCTP stream crashes you'd try a reset and try to 
establishment, etc? Do we need an updated SDP O/A? Also given that CLUE 
would only be one of several possible WebRTC data channels what 
behaviour do these have?

> a) I send a first SDP containing both the (non-CLUE-controlled) 
> available media and the m-line associated with the new CLUE channel I 
> want to setup. As an example, the excerpt below assumes one video 
> stream (with mid=2) is already available when I start re-negotiating 
> the  CLUE channel (whose mid is 5).
>
> ...
> a=group:CLUE 5
> ...
> m=video 6002 RTP/AVP 96
> a=rtpmap:96 H264/90000
> b) Once done with channel setup, I send a new SDP which simply adds 
> the video stream with mid=2 to the CLUE group, in order to indicate 
> that the stream in question is going to be CLUE-controlled once again:
>
> ...
> a=group:CLUE 5 2
> ...
> m=video 6002 RTP/AVP 96
> a=rtpmap:96 H264/90000
>            e-mail: [email-masked] <mailto:[email-masked]>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 23 Jan 2015 10:07:34 +0100

Hello Christian,

my further comments in-line.

> [CNG] I think the argument was that the IETF defines RFCs to support IETF protocols i.e. SIP. So if you use CLUE outside of IETF you can ignore the requirement. e.g. H.323 is being updated by in ITU-T SG16 Question 5 to also support CLUE. My opinion is that in the CLUE WG we should focus on SIP but if someone wants to also use CLUE with other protocols then that's good for CLUE. So I'm happy to relax the statement.

[SPR] The example I was making (CLUE with RtcWeb/WebRTC) is 100% INSIDE the IETF, isn’t it?

> [CNG] Wouldn't this depend on what layer the CLUE channel error occurs? e.g. if CLUE crashes then you simply resend OPTIONs etc. on the existing SCTP stream. If the SCTP stream crashes you'd try a reset and try to establishment, etc? Do we need an updated SDP O/A?

[SPR] As I was trying to explain in the SDP excerpts, I think the new O/A is needed in order to: (i) setup a new CLUE data channel; (ii) put the (non-clue-controlled) existing media under CLUE control.

Cheers,

Simon

                     					       _\\|//_
                           				      ( O-O )

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Jan 2015 13:33:24 +0000

Hi,

> Do we really need to state that SIP is mandatory for CLUE? I mean, our feeling is that the current specification of CLUE actually gives for granted that we use a mix of SDP and CLUE-level information in order to properly setup (and modify) a CLUE-enabled > session. Now, SDP can be sent back and forth between two CLUE-enabled end-points in a number of different ways, SIP being just one of them. Clearly enough, I am thinking of the WebRTC scenario, whereby we might initially leverage a signaling server in > order to exchange SDPs between Producer and Consumer. In that case, the very first SIP session setup (which is needed in order to create the CLUE data channel) might be replaced by a "signaling-server-mediated" WebRTC session negotiation. Once the 
> session is up and running, further SDP objects (used to negotiate CLUE-controlled media) might be transferred directly across the CLUE channel, in much the same way as it happens for CLUE protocol messages, with no further need for a third-party 
> mediator.
> I am not stating here that we have to bend towards this second approach; though, I do think we might somehow relax the SIP requirement and allow for more than a single alternative in CLUE. What's your feeling about this?
>
> [CNG] I think the argument was that the IETF defines RFCs to support IETF protocols i.e. SIP. So if you use CLUE outside of IETF you can ignore the requirement. e.g. H.323 is being updated by in ITU-T SG16 Question 5 to also support CLUE. My opinion is 
> that in the CLUE WG we should focus on SIP but if someone wants to also use CLUE with other protocols then that's good for CLUE. So I'm happy to relax the statement.
>
> [SPR] The example I was making (CLUE with RtcWeb/WebRTC) is 100% INSIDE the IETF, isn't it?

In my opinion, the purpose and scope of the CLUE *WG* is to define how the CLUE *protocol* is used with SIP/SDP.

I see no reason to forbid others from defining usage of the CLUE *protocol* in other environments.

-------------

> As per our discussions at the last IETF, the group seemed to agree on the fact that in the event of a channel error during normal CLUE operation, the media that were being CLUE-controlled do not have to be torn down and can instead keep on going (even > in the absence of CLUE control). If we go to the CLUE participant's state machine (section 6 of the protocol draft) this means that we do not have to release resources in this case, but simply move to the "Idle" state and start the CLUE channel creation 
> phase once again. In such a situation, we would find ourselves in the need of: (i) re-establishing the CLUE channel; (ii) adding the already available media (those which were CLUE-controlled before channel crash) to the newly provided CLUE channel.
>

I am not sure I understand (ii). How is putting non-clue-controlled media under CLUE control related to a crash of the CLUE channel?

I don't think you need a new SDP O/A in order to re-establish the data channel, unless some associated parameters have changed, or if you realize that it doesn't work (perhaps some gates that were opened for the data channel have been closed due to the failure).

Regards,

Christer