Options to Transport CLUE Messages Stephan Wenger Roni Even Gonzalo Caramillo Marshall Eubanks 1

Constraints SIP to be used as base protocol for call setup – Charter, backward compatibility “Framework” draft requires (for valid reasons) handshake different from what is commonly used in SIP – (offer/answer (OA) vs. three-trip handshake) It would be desirable to have single phase session setup, but that would mean using SIP-INVITE for (at least the initial) CLUE information, and not compatible with “framework draft” Unclear whether there is conceptual difference between “initial” CLUE information, and CLUE information exchanged during the lifetime of a session. Suspicion: no significant difference 2

Conclusion #1 Need two stage “negotiation”: first SIP, then CLUE – Can probably overlap at least partially 3

Options for transporting CLUE exchange Piggy-packing on SIP (SIP-INFO, SIP-UPDATE, RE-INVITE) – INFO: need a package? – UPDATE: unclear whether appropriate, depends for example on whether SDP is an efficient representation for CLUE messages (probably not) – RE-INVITE takes too long, commonly codec boxes tear down everything during re-invite, tens of seconds Content indirection, multi-MIME body, allows non-SDP – FTP and config files (as TeleSuite did) CLUE stream as a SIP-negotiated “media” stream – Message Session Relay Protocol (MSRP, RFC 4975) – CLUE-WG devised selection – Other transport 4

Conclusion #2 CLUE stream as a SIP-negotiated “media” stream 5

CLUE negotiation over SIP-established “media” stream Setup “CLUE” media stream through SIP w/ OA – Offer CLUE+initial (mono, G.7110 audio, also offer CLUE-less full conference for backward compatibility.) Assumed OA result: “CLUE” session goes through CLUE handshake over CLUE “media” stream Based on results of CLUE handshake, setup of full audiovisual functionality by SIP-UPDATE or SIP-REINVITE – To re-use existing functionality in codec boxes – CLUE as a bolt-on 6

Ladder Diagram 7

Options for CLUE “media” stream UDP recommended because of NATs, firewalls, ICE, whatnot Alternative: ICE-TCP Problem: UDP is unreliable – Packet size under MTU: no issue, redundant sending, but unlikely given complexity of CLUE That’s assuming XML-ish representation. Perhaps can use compression, binary model, …? – Use RTP? And its reliability support (retransmission, redundancy, FEC)? – Devise our own BFCP-like handshake 8

Conclusion #3 CLUE WG to devise our own BFCP-like handshake to make CLUE media stream sufficiently reliable 9

CLUE message Content Representation As suggested, we are NOT constrained to use SDP; modern, flexible formats are OK XML natural candidate Is CLUE presentation in XML exceeding UDP MTU? Probably yes, especially for multipoint Need to make CLUE “media stream” reliable enough (see previous slide) 10

Conclusion #4 Use XML for CLUE message content representation 11

Conclusions Summary 1.Need two stage “negotiation”: first SIP, then CLUE – Can probably overlap at least partially 2.CLUE stream as a SIP-negotiated “media” stream 3.CLUE WG to devise our own BFCP-like handshake to make CLUE media stream sufficiently reliable 4.Use XML for CLUE message content representation 5.Gonzalo, Roni, Stephan, to write -00 draft 12