Subject: [clue] framework editor notes about RTP and SDP need to be resolved

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 13 Jan 2014 06:03:48 -0800

framework-13 has a couple editor notes about managing RTP channels, which I think we can resolve by removing the potentially complex optimization idea.

>From section 5:
"Numerous optimizations are possible, and are the implementer's choice.  For example, it can be sensible to establish one or more initial media channels during the initial offer/answer exchange, which would allow, for example, for a fast startup of audio.  Depending on the system design, it can be possible to re-use this established channel for more advanced media negotiated only by CLUE mechanisms, thereby avoiding further offer/answer exchanges.
Edt. note: The editors are not sure whether the mentioned overloading of established RTP channels using only CLUE messages is possible, or desired by the WG.  If it were, certainly there is need for specification work.  One possible issue: a Provider which thinks that it can switch, say, a audio codec algorithm by CLUE only, talks to a Consumer which thinks that it has to faithfully answer the Providers Advertisement through a Configure, but does not dare setting up its internal resource until such time it has received its authoritative O/A exchange.  Working group input is solicited."

>From section 10:
"Edt. Note (StW): is the sentence below still correct?
Even more advanced devices MAY choose to establish media streams without an offer-answer exchange, for example by overloading existing 5 tuple connections with the negotiated media."

I think we have a better way to describe how CLUE protocol interacts with SDP, details of which are in the signaling document.  Section 4.4 of draft-kyzivat-clue-signaling-05 describes how SDP media lines are associated (or not) with a CLUE control channel.  I think this means it is not possible to use the same m-line both with and without CLUE, contradicting what is proposed in framework section 5.

For framework section 10, I think the intent is to say CLUE advertisements and configure messages don't necessarily require a new SDP offer/answer for every CLUE message exchange.  But the resulting encodings sent via RTP must conform to the most recent SDP.  Is this correct?

If the group agrees with my interpretation, I will change the text in the framework to be consistent with the signaling document.

Mark