Subject: Re: [clue] New draft on Transport Options for Clue

From: Paul Witty <[email-masked]>
Date: Wed, 02 Nov 2011 12:32:53 +0000

My thoughts on it from a first scan...

    There is no hard real-time transmission requirement for CLUE
    messages; latencies in the seconds range are acceptable.
-- provides a bad user experience if initial media takes seconds

Option 1 : Piggy-pack on SIP
-- Not guaranteed to get through back-to-back user agents
-- agree that SIP INFO is the way to go if chosen
-- endpoints may have issues with receiving large SIP messages

Option 2: CLUE control channel on the media plane over UDP
-- Like BFCP, so the question as to whether signalling is acceptable in 
the media plane seems to have been already answered
-- Congestion control can be assumed to be less important as bandwidth 
of CLUE should be much less than that of media
-- Need to make UDP reliable
-- Need to support CLUE messages larger than MTU, so will need 
additional encapsulation e.g. sequence numbers
-- Will end up implementing TCP-over-UDP or similar

Option 3: CLUE control channel on the media plane over TCP
-- Tried for BFCP - abandoned in favour of UDP

Option 4: CLUE control channel over UDP and RTP
-- Retransmission/FEC can be used on things other than RTP - seems 
likely that endpoints supporting CLUE will generate/process CLUE 
messages in a different place to media, so possibly no advantage in 
reusing RTP over implementing the same schemes again - RTP is for real 
time things i.e. not CLUE.
-- May have an advantage that SBCs are already used to passing RTP 
through, so may get through where other data over UDP does not

Option 6: HTTP
-- No guarantee a device is reachable over HTTP, particularly when SIP 
is to a local call control device (as well as possibly proxying media, 
such that nothing is ever sent directly to/from the far end)

Clue Discovery
-- Can possibly include a simple parameter in the SDP to state that a 
particular media session can have its contents controlled by CLUE.  We 
need not just discoverability of CLUE, but negotiation i.e. if one end 
supports CLUE and the other does not, we should fall back to a non-CLUE 
SIP call.
-- May be advantageous to send something in the SIP headers, so that 
even in the case of delayed offer we know that the fair end supports 
CLUE at the earliest possible opportunity

-- 

Paul

On 25/10/11 04:44, Marshall Eubanks wrote:
> We just published a draft on Transport Options for 
> Clue, draft-wenger-clue-transport-01
> (it's -01 as I fixed some issues with the author list in -00).
>
> http://tools.ietf.org/html/draft-wenger-clue-transport-01 :
> A new version of I-D, draft-wenger-clue-transport-01.txt has been 
> successfully submitted by Marshall Eubanks and posted to the IETF 
> repository.
>
> Filename:        draft-wenger-clue-transport
> Revision:        01
> Title:           Transport Options for Clue
> Creation date:   2011-10-24
> WG ID:           Individual Submission
> Number of pages: 9
>
> It clearly needs some work...
>
> Regards
> Marshall
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Nov 2011 20:35:49 +0100

The charter for bfcpbis does not propose to remove the capability for TCP. Rather it is adding an option for UDP.

There are perfectly valid usages that specify only the support of TCP, and are specifying that TCP should work through NATs.

I'd also note there are other TCP usages defined in this area. Look at MSRP and also at the mediactrl control channel framework.

Regards

Keith

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Witty
Sent: 02 November 2011 12:33
To: [email-masked]
Subject: Re: [clue] New draft on Transport Options for Clue

-- 

Paul

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Wed, 2 Nov 2011 23:04:01 +0100

The protocol design will be more straight forward if we could assume
that the transport had the features of being in-order, reliable and
allowed large messages (e.g. 20+kb XML messages). 

Regards 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DRAGE, Keith (Keith)
Sent: 2. november 2011 20:36
To: Paul Witty (pauwitty); [email-masked]
Subject: Re: [clue] New draft on Transport Options for Clue

The charter for bfcpbis does not propose to remove the capability for
TCP. Rather it is adding an option for UDP.

There are perfectly valid usages that specify only the support of TCP,
and are specifying that TCP should work through NATs.

I'd also note there are other TCP usages defined in this area. Look at
MSRP and also at the mediactrl control channel framework.

Regards

Keith

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Witty
Sent: 02 November 2011 12:33
To: [email-masked]
Subject: Re: [clue] New draft on Transport Options for Clue

-- 

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Nov 2011 17:51:11 -0500

[as individual]

Here are some comments I accumulated while reading through this draft:

There are some character set issues in this draft, at least as its 
represented in my browser. I'm seeing things like: "Oon the wireO". The 
first and last characters there are (to me) "O". I presume they are 
intended to be some sort of quote, and that there is a character set 
conversion problem.

There is a paragraph beginning "In version -00 ... we ...", implying 
that this *is* version -00. But its now -01.

Regarding the CLUE messages: I'm lacking a clear specification of the 
sequence in which these messages may be sent. IMO a state machine would 
be helpful to clarify this.

3.1 - use of UPDATE

The limitation on use of update is really wrt o/a. (If an UPDATE 
contains an offer, and answer must be in the response to the update.) It 
is really irrelevant to other uses of UPDATE, to convey things other 
than o/a. You should not exclude it just for this reason. But I agree 
INFO might be a better choice for tunneling clue messages in SIP, 
assuming its not necessary to send them with the initial INVITE.

3.2

Another issue here is reliable message delivery. UDP doesn't provide it. 
Defining it in a one-off fashion on top of UDP is a pain, and a 
distraction from the real work of CLUE. ISTM it would be best to 
reference some existing reliable transport that has suitable properties. 
(Perhaps one layered on UDP.)

3.3

The issue of keep alive messages seems something of a red herring. *any* 
reliable mechanism is likely to require keep alives.

4.1 - Using SDP

This alternative is more "encumbered" than the others, because using SDP 
with SIP implies using the o/a model, which doesn't currently align well 
with the framework. So it needs to be considered in a different light 
than the others.

For instance, use of SDP means tunneling in sip messages, and then SIP 
handles the transport issues. It also implies using SIP solutions to 
message size - requiring use of TCP for large messages.

	Thanks,
	Paul