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

[Paul Witty <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue