Subject: [clue] issues for call flows

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 Jun 2012 22:46:53 +0200

(as individual)

The following is directly in response to the interim, but its with 
regard to the call flows that are going to be written before Vancouver. 
It also reflects my assertion that we will need a state machine.

ISTM that there are some fundamentals that aren't worked out of how call 
flows work. In particular, I'm concerned with the interaction between 
the clue messaging and sip o/a.

It seems clear that some clue messages will demand a new sip o/a. But 
its not obvious which ones. The likely trigger is that receipt of a 
client-configuration message would result in an o/a to arrange the media 
streams to accommodate that configuration. But if we aren't careful, we 
could end up in a situation where every change results in an o/a glare 
situation. Ideally, during the initial setup the first offer that 
reflects the clue negotiation should be sent by one end that has both 
sent and received a client-config message. And then the offer should be 
sent by the other end after it receives a client-config message. But 
there is a potential race in receiving messages, so glare is still 
possible unless one side is designated by the protocol to send that offer.

Subsequently, changes on the two sides are likely to be asynchronous and 
uncorrelated. So that same algorithm won't work. Then it might be 
sufficient to initiate a o/a upon receipt of a client-config. But we 
will still have new kinds of glare to deal with, such as a client-config 
sent concurrently with an advertisement in the opposite direction. 
(Because advertisements by each side are independent, there should be no 
glare between them.)

Upon sending a new (not first) advertisement, is is possible that there 
will be no corresponding client-config? Its certainly possible to 
imagine situations where a new advertisement is a superset of the prior 
one, so that the prior client-config is still meaningful. Conversely its 
also possible to imagine that conditions have changed and require 
sending a new advertisement that has nothing in common with the prior 
one. If so, it would seem that a new client-config would be required.

What should be done about those streams previously negotiated until a 
new config is received and o/a reflecting it concluded? Presumably there 
is an obligation to continue sending *something* meaningful in the 
context of the prior config and o/a, even if the sources to satisfy that 
config are no longer available.

The flip side of that is: when a device has sent a client-config, how 
will it know when the media it is receiving is in accord with that new 
config and not with the old one? (Note the o/a exchange is not 
synchronous with receipt of corresponding media.) It may be necessary to 
manage the identifiers of captures within the media streams so that it 
is always clear when the changeover has happened.

Normal sip has similar, but easier, issues. When you send an 
offer/answer you must be prepared to immediately receive media on the 
media sessions you offered/answered. But for awhile you also must be 
prepared to receive according to the sdp previously in effect, and be 
prepared for the reinvite/update carrying the o/a to fail, in which case 
you must be able to continue as if you had never done it. There is no 
rule about *what* you must do with this received media, but doing the 
wrong thing and result in a bad product. CLUE adds more cases to this, 
and the expectations for handling things well are no doubt higher.

The call flows we come up with must be consistent with
a set of communication rules (protocol) that deals with all these 
issues. For instance, it might be necessary to identify each 
advertisement, and for each client-config to reference the advertisement 
it pertains to, and for a client-config to fail if it doesn't reference 
the most recent advertisement. Similarly it may be necessary for each 
offer and answer to reference the two client-config messages (one from 
each end) that it is fulfilling.

	Thanks,
	Paul