Paul- Your request (below) is a good one, and I will try to give a little history (as I saw it). Anyone please correct me if I get it wrong or leave something out.

Several considerations by several people (François, Jill Caugherty, myself, and others before us) led up to this question: 1. H.245 takes a considerable number of sequential messages to accomplish the reconfiguration or replacement of a media path. This especially true in the Gatekeeper-routed model. Fast Connect avoids this overhead initially, but delays the establishment of the H.245 channel for later use. 2. It is desirable to negotiate, or be aware of, FAX capability early on without opening a FAX channel. 3. It is desirable to negotiate end-to-end digit handling (or other capabilities) prior to opening an H.245 channel, i.e., in the presence of fastStart. It's also desirable to get the startup overhead (TCS exchange and M/S negotiation) of H.245 out of the way early. 4. FastStart provides a means of passing some (but not all) capabilities from the caller to the called endpoint, but it cannot convey the equivalent information in the reverse direction. (The reverse information implies establishment of the corresponding channel.)

I had been working on a proposal for repeated fastStart for any end- point (not just Annex F) that was intended to allow either party to reconfigure channels. My scheme used a null-data OLC from the caller in addition to the normal fastStart offer(s) to indicate that the caller is willing to do repeated fastStart. The called party could then accept fastStart (by returning standard OLCs), and indicate repeated fastStart by returning the null-data OLC, then offer additional OLCs with capabilties that could be used later. François suggested that the sending of the TCS in the H.245 tunnel in parallel with the fastStart would be an alternate (and more efficient) way to exchange the caps (and would have the advantages of getting the overhead of starting H.245 out of the way). We documented both ideas in APC-1823 in Osaka. The idea of repeated fastStart (except for Annex F) met with disfavor in Osaka (and before - Dave Walker and Pete Cordell pointed out their earlier contributions with regard to improving H.245 performance APC-1522 and APC-1524). The idea of overlapping capset exchange and M/S negotiation with fastStart was adopted, however, as described in TD-26. This was seen as a less-radical change, but has clearly met with some resistance due to backward (in)compatibility. As a result, we seem to have solved nothing. I'd like to go back to the original efforts to see what could be done. It seems that the key to the problem is how to say "we want to do some- thing new" in a way that is backward compatible with earlier versions. I had proposed to do this with a "null OLC" (dataType = nullData) in order that no ASN.1 changes were required. Jill's contribution suggested an extension of the DataType to permit the choice of UserInputCapability. This, or any new capabilty (e.g., "repeatedFastStart" [my personal favorite], or "terminalCapabilitySet" [François' favorite]) could be added to the dataType and could then be sent in OLCs with multiplexParameters = none in a fastStart element. This should be backward compatible since the OLCs would be well-formed. (I will note that this places us in the interesting position of defining elements in H.245 to be used when we're not doing H.245. It's like an American defining a new French word so it can be incorporated into English.) The terminalCapabilitySet option would be very powerful: it could include user capabilities and maxPendingReplacementFor as well as media capabilities, and it avoids the problem I tried to solve by separating OLCs into "acceptances" and "offers" (via placement of the null OLC). If the called endpoint does not support (or does not recognize) a new capability, it will not reply with a matching OLC (it can reply with matching media OLCs to accept standard fastStart); if it does accept a capability it can reply with the appropriate matching OLC (e.g., one containing its own capabilty set). As with standard fastStart, if the called endpoint does not accept a capability, the originator should not use it. I should note that some capabilities such as DTMF digits We could, of course, extend the OLC forwardLogicalChannel dataType to include masterSlaveDetermination and masterSlaveDeterminationAck or some such. (It would be nice to define the procedures such that the called party always broke ties, so that the procedure always succeeded.) But look what this leads to: we're building H.245 into the fastStart element. And why would we want to do this? I claim that the real incentive is the same as it has always been for fastStart: we want to speed things up. FastConnect (which, I understand, we agreed in Osaka to call FastStart) has the advantage of a single-exchange sequence: endpoint A proposes and endpoint B accepts. Both media directions are handled in parallel, and either endpoint can insure that both codecs are the same, if they wish. H.245 procedures have, I believe, the distinct speed disadvantage of requiring the source end to initiate and close a logical channel, which then requires the other end (or a gatekeeper) to request that a channel be opened or closed. (BTW, the RequestMode message to do this is not entirely satisfactory since it can specify a "mode" [e.g., G.729], but not a capability [e.g., G.729 with 2 frames - unless you pick g729AnnexB or a later addition - there seems to be an inconsistency in the extensions to AudioMode!) The trick, I guess, is to update the TCS to include only the exact thing(s) you want to do now, then hit the endpoint with the RequestMode. Some of this was discussed in TD-33a from Osaka. Anyway, Paul, this has become way too long (no pun intended), so I better stop. I hope this helps. -Bob ---------------------------------------------------- Bob Gilman rrg@lucent.com +1 303 538 3868

Paul Long wrote:

Paul,

Unfortunately, I wasn't in Osaka. Would it be asking too much to ask what problem this was supposed to fix? Maybe we can come up with a fix that won't break something else. That would be the ideal solution.

Paul

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com