Strange states: January 26, 1987 11:39:13 am PST Thrush Not only should ChangeState and Progress detect calls left in the initiating or notified state, but also there should be a time-limit on how long these states may be allowed. Perhaps combine with present deferAnswer timing? Yup. Progress should look at whole list of convs, make sure max one is in a state demanding conneection to a voice terminal, zap the rest. Finally do it right, that is. Do same thing for LarkTrunkSmarts, possibly BluejaySmarts. Not clear anything is needed in FinchSmarts -- either the user can zap manually or roll back or it doesn't matter. January 14, 1987 11:22:48 am PST Thrush It's possible to leave Larks permanently in bad states when Finches screw up. For instance, if you run a buggy Finch and then try to make a call, it can leave your Lark in initiating state, which doesn't prevent you from making FD calls, but does prevent BD calls due to FD/BD conflict comparisons. What causes FD initiating thing to get forgot by the Finch, even though it stays in the fray. Have seen a similar "notified" situation. Need some sort of timeout on those states? Blagh. Looks like currentConvID can get cleared while one is still in the initiating state, or maybe there are situations where it never gets set but the initiating state isn't left anyhow. Probably requires that Finch do the initiating and that it fail without appropriate action in the process, but sheesh. January 13, 1987 11:50:58 am PST Thrush There are situations which leave things in a strange state. For instance, killing a Finch when it doesn't have a Lark doesn't idle the Finch in the conversation, even though there's no one to splice. So a party remains in notified state and leaves conversations around. Harmless enough, but annoying. Since can't select conv, there's no user interface way to grab them and get rid of them. They don't splice back in when Lark comes back, neither. Not sure how to characterize that, but try. December 22, 1986 2:31:45 pm PST All Must now once and for all decide how to handle multiple calls in LarkSmarts; once past the notification hurdle, that is. Must somehow assume that it's OK to be in multiple conversations, and that somebody else will take care of the adjudication (like multiple-activeness). Just finish the inactive/mustActive .... state table and hope for the best. Each progress opportunity should scan all existing conversations and decide what to do about each. Use some switching notion to determine which one (ones in the funny-conference case) is connected to the hardware. Think about something that refreshes the list of convs. in a smarts from the Party, or something. Somehow they should come to look like caches, not different truths. Recent thinking: some conversation states (reserved, parsing, ringing, active) require connection to the hardware, some don't (notified, initiating, inactive). LarkSmarts should be conservative about proposing new conversations (Finch needn't), but liberal about rejecting new attempts to require the hardware when previous conversations have already succeeded. Such an attempt is an error or is due to a race (stateMismatch doesn't apply across conversations). February 10, 1987 8:36:59 am PST Thrush Add some simple statistics. # total calls, time started, # trunk calls, # service calls (by service?), # attempted/completed, current # calls in progress. Think about a (temporary) display indicating who they are? January 19, 1987 5:43:15 pm PST Thrush Redesign decisions about when to cancel visiting. February 12, 1987 7:48:39 am PST All Consider the LoganBerry conversion for NamesGV (all of it???????) February 10, 1987 6:04:04 pm PST VoiceUtils NamesGV.Authenticate should compare keys before returning. Also NamesGV interface (and all other RPC interfaces) should allow for secure communication, and demand it for updates. The allow-for part has to be done at a time when the server is being upgraded. Dont' do this if you're going to replace the whole thing with LoganBerry, of course. February 11, 1987 7:36:01 pm PST All There isn't a version-numbering strategy for any RPC interfaces except for the actual ThParty/ThSmarts ones. Probably should be. December 29, 1986 11:34:39 am PST Thrush/Finch Synthesizer playback very flakey. Sometimes the utterance is cut off, as if it is being played before the connection is fully established. Possibly should play the KeyDistribution trick with a bogus key, just to synchronize? Other times it doesn't play. Situation is confused by same-machine RPC failures between Finch and Thrush on same machine. Need to wait for more standard test, and until Finch handles timeouts and failures better, before continuing this investigation. November 26, 1985 4:09:21 pm PST Thrush P: showslower: no good methodology for killing and reregistering Bluejay parties -- automatically, anyhow. April 21, 1986 3:40:20 pm PST Thrush Service larks (T-T-S, radio) are defenseless against back-door callers (except by not plugging in the back door, of course). There's no way to detect when the other party hung up. No dial-tone or click-detection, and anyway, in the case of the radio server, the hybrid bounce from one's own noise would drown out any ability to do it. Consider watchdog timer thing of some sort, not sure what, to deal with this. Should this be disallowed and prevented? Best thing to do is disallow connections from back doors to services? How about all the things people want to do about recording calls and the like? December 22, 1986 2:11:42 pm PST Finch error reporting in Finch needs to be reanalyzed. For instance, when calling self, complaint is "no valid party found", accompanied by the "philosophical" comment passed on from LarkSmarts. June 22, 1986 9:07:53 pm PDT Finch Conversation ID management in Finch is a total mess. Everybody seems to have to know who's who. Some don't. Idea: have a notion of "the connection to the voice service". Seldom valuable to have more than one, and in those cases we'll be controlling it. Use it if it's around. Inactivate it when not in use (rather than shutting it down in Lark) and Zap only after a while. Can inactivate when receiving incoming calls, etc., too. Maybe Flush and restart. Food for thought. December 23, 1986 3:49:42 pm PST Finch Many to/from confusions about who's calling whom, esp. BD incoming calls. February 17, 1986 6:08:55 pm PST Finch 5. Finch, when told that self is no longer poaching, or when it drops out, should unselect the present conversation and either make a separate conv log entry (not all entries need be conv Descs any more, could have entry for each connection and disconnection!) or record dubiousness in last entry. Mostly won't know about these situations, because server will forget about us. How to tell when one has been hung up on? Need a function in FinchSmarts in case there's still communications. Does this beat against the Queue flushing that's done (is it?) when a Smarts goes away? Maybe should be flushed only if communications fails. This might happen when a new poacher comes along. FinchToolImpl.CheckActive: PUBLIC PROC[handle: FinchTool.Handle] RETURNS[active: BOOL_FALSE] = TRUSTED { IF handle#NIL AND handle.finchActive THEN RETURN[TRUE]; StartFinch[]; RETURN[handle.finchActive]; }; tries to return NIL.finchActive if Finch not active when called. Looks like StartFinch was supposed to fill in handle. Breaks because even if StartFinch produces a handle, if there wasn't one before there still isn't. So the "Phone" command, issued before Finch has been manually started, fails. July 15, 1986 7:14:11 pm PDT Thrush/Finch Polling doesn't scale, if it's the primary means. But it is necessary to catch deaths that occur during hiati in communications. Right now there's no polling at all in the voice system. And there needs to be. Alternative: make it always harmless to have a hiatus; for instance, Finch can catch up with the call log when it and the server have been out of contact. January 19, 1986 3:42:40 pm PST Finch When Finch drops out, most recent conversation log entry remains selected. Should probably put distinctive value in there and deselect. If Finch restarts during same conversation, either compare convID's or just start a new entry. November 26, 1985 4:09:21 pm PST Finch Finch checks in once in a while, re-registers if gone. June 11, 1986 6:19:11 pm PDT Finch Maybe don't have to analyze error situation in Thrush, but Finch is truly a mess, and adding side paths for VoiceRopes makes it worse. Have really got to get that under control. Monitors, when and where to complain, and the like. Look at VoiceDB stuff for some guidance in options of who reports and all. May 4, 1986 11:49:14 pm PDT Finch Need specific tests in FinchSmarts for $voiceTerminalBusy, and a better response in error log. "no valid party found" should be replaced by the comment if there is one on failure. December 18, 1985 11:21:07 am PST Finch The error reporting/management in FinchSmarts is as confusing as ever. Some things are reported as problems directly by FinchSmarts, others in a form of conversation state reporting to FinchSmarts client. Most of the error checking in the present rendition is minimal, awaiting a thorough review. FinchTool will just have to cope. February 4, 1987 6:28:31 pm PST VoiceUtils Document the interfaces that are available in VoiceUtils. People might find many of them useful. January 19, 1987 5:42:26 pm PST All Document recent database additions somewhere, like $multiring and $deferanswer. June 26, 1986 9:33:49 am PDT All Document briefly the list of recent improvements. April 28, 1986 1:18:55 pm PDT DOC Document new meanings for **7, **8, **9, *0name# => *name#, new monitor-mode stuff (hard). June 19, 1986 8:51:48 pm PDT Thrush/Finch Consider ThParty call that returns updated ConvEvent (self=other) to update state. Then stateMismatch can be upgraded in a loop. Consider NoteNewState change so it never does anything directly (never does, anyway, except during notification, which has to be the first we've heard of the event anyway. Can the WhatNeedsDoing stuff be pruned further? June 17, 1986 10:45:54 pm PDT Lark Think about having Zap clear out voice-related sockets somehow, to save on the number of necessary calls. Probably the non-zapping version was trying to save on calls. There can still be a 400A occasionally, when things go wrong. Rebooting will usually be OK in these situations, though. August 9, 1986 3:22:26 pm PDT Thrush Design methods for recording calls, playing back stuff to all/chosen parties. Needs flexibility, needed also for radio broadcasts and such, for one-way traffic on some links, dynamically determined. June 28, 1986 10:37:22 am PDT Thrush Longer-term solution to the ringing-once-per-cycle problem: Callers who can't get through immediately should be able to persist: must be able to recognize rejection states from callees. Callees willing to allow calls to persist and even eventually succeed must enter states they can get out of. Maybe inactive is good enough? Callers, similarly, when they want to persist, must enter states they can later get out of. Error may work, except for the special treatment of notReallyInConv that might conflict. Now things like increasing the priority, if reported as events, could allow real-time alteration of the treatment of existing calls, and like that. June 26, 1986 9:32:57 am PDT Recorded voice Doug or I has to decide how to use the ambient-level stuff, experiment with thressholds. It is now possible to set the silence threshhold for a Lark from Thrush, by the way. February 2, 1987 10:55:34 am PST All Provide facilities for determining in Finch if the Lark is up and functioning. Actually, GetParty["Self", $telephone] should do pretty well. Then need better control over busy-handling for the simple procedures like TextToSpeech[...]. Definitely need some workstation-side packaging. This is in response to Fiala's complaints. January 30, 1987 1:58:25 pm PST BluejaySmarts Doesn't have the corresponding notion of Fail that Lark does. When $noSuchSomething comes up, it's not likely that the smarts will even clean up the conversation, let alone drop out and start a new one. This can probably be deferred; failed recording parties represent serious problems that should be found and fixed. January 28, 1987 7:54:54 am PST Thrush nb and reason should be merged. Makes it harder to index things by reason, but could use a hash table for that. December 23, 1986 3:37:38 pm PST All StateInConv -> ATOM, and find another way to do state comparisons when necessary. Allows more flexibility in assigning new states. Make sure there's a way to find all of the assigned values, though. December 23, 1986 3:38:46 pm PST All Add $monitored state: like $inactive, but party doesn't really intend to come back -- wants to observe other transitions, though. Good for Agent stuff? Can come back as long as somebody's still in the conv., but should go away if everybody else is either $monitored or $idle. December 23, 1986 3:48:46 pm PST Thrush Option: don't override volume control during ringing; for development. December 23, 1986 3:49:01 pm PST Thrush Program control over ring volume, better than now. December 8, 1986 6:45:51 pm PST Thrush key distribution: not satisfied with how it's done -- the report when all reports done thing is a kludge. Should distribute keys, wait for input events (from larks) or equivalent, send in a complementary report which counts. Maybe the original report can contain a handle on the service that's updating the keys and one can communicate directly with it. Anyway, could then remove the hairy report stuff from Thrush. August 14, 1986 11:23:03 pm PDT Thrush Need a way to register behaviors with LarkSmarts. Could be through additional smarts mech., but they're gone. In any case, things like call filters and so on should be handled that way. Prose specials, all that sort of thing. Too much is done in line. General registration mechanism. Extension of service registration? Don't know. Not an issue if Finch is supposed to do most of the hairy stuff. March 14, 1986 6:59:43 am PST VoiceRopes Should Tune-archiving information be written into Tune headers, along with keys, voiceFileID's, creators? March 2, 1986 11:43:27 am PST VoiceRopes If one records a long rope, one might want a way to checkpoint the partial results, or at least record the existence before it completes/shortly after it starts. Also, want unvoice-activated terminations ---- recordings that stop when the speaker stops for long enough. March 2, 1986 11:44:04 am PST VoiceRopes Silence threshhold is something Bluejay could pay attention to on recording, independent of Lark choices. February 22, 1986 3:48:57 pm PST Thrush Rework all the user profile values, combine where possible, use Intervoice prefix February 4, 1986 8:37:38 am PST VoiceRopes LoganBerry calls from VoiceDB are not encrypted (!!) January 27, 1986 7:03:14 pm PST VoiceRopes Walnut forwarding needs to have hooks allowing programs to run. For instance, the VoiceFileID's of the forwarded message need to be able to be substituted. We also need a way to recopy (forward assuming you're sending it again.) December 18, 1985 12:04:27 pm PST Thrush I'm no longer convinced that queueing is needed in the Smarts at all. Probably one for the Lark keyboard, just to keep the characters flowing, but otherwise, now that conversation state is reported back for each call, it may not be necessary. Seems artificial every time I queue something. WaitForActive also has to do something like that, but a simple condition variable thing might well be good enough there; Progress is reported in its own process. November 26, 1985 4:09:21 pm PST Thrush Make sure there are routines for setting conversation attributes (subject, urgency, ...) after initial creation. November 26, 1985 4:09:21 pm PST All Logging, statistics, performance measurement. December 18, 1985 11:47:13 am PST (optional) All progress report (pd.reports) output has been removed from both Thrush and Finch. Consider what's needed when thinking about statistics gathering, logging, error management. January 11, 1987 2:57:09 pm PST Thrush Lark buffer connections now complicated enough that a differential approach is the desirable way to avoid unnecessary break/make sequences. Just the way hardware switching is done now. December 22, 1986 1:49:02 pm PST Thrush Suppose Party A alerts parties B and C, each of which have the same voice party. This is a case with the same problems as the narcissism case. Can it arise? December 18, 1985 11:52:35 am PST Thrush Think about whether a common set of smarts implementations at some level would make sense. August 12, 1986 6:13:17 pm PDT All Idea: many smartses seem to need (1) notification when something happens and sometimes (2) a way to wake up once in a while even if something hasn't happened (most recent example: ringing for only a while after somebody else has answered, and in fact somebody else might have answered first. Can we do anything at ThParty level to regularize this? Notify in time t would be fairly easy (all or just me!). Would be nice to have some value that would travel across and back without damage, so that the notification could include, for example, a call-back proc!!!!! See, the trouble with waiting for some event is the standard problem with waiting for two kinds -- user input and the other kind. Could we just do smarts behaviors all by Progress events? So that all smarts actions are defined by stream of such things. Like lists of ref any or something? Then with the timeout, we've got something manageable, sort of. What is then the relationship of this to what WS clients of smarts do? Have to think this out. In meantime, just do something. June 2, 1986 7:48:16 am PDT All Think about adding a local interface record to the service registration stuff. All these interfaces must be of the multiple-import type, just to avoid hassles. Document that, too. April 21, 1986 3:40:20 pm PST Thrush Pity DTMF detectors also don't do dial tones, busy tones, and the like. Maybe some do. February 23, 1986 1:49:37 pm PST What would it take to make BD all analog again? February 23, 1986 1:49:54 pm PST "who is talking" feature during teleconference, other high-performance stuff based on voice content; how to control? Control over who is talking, meets Stodolski's requirements. December 19, 1986 1:45:04 pm PST Finch indicate real names of people, rather than RNames, in Finch log. Real names on screen, both names in permanent log? December 23, 1985 1:37:37 pm PST (optional) PartyInfo called in FinchSmarts uses nameReq: $description to get most human-sensible description. Then FinchToolImpl.ReportConversationState has to strip off extraneous stuff for calling/called party fields. nameReq: $current would usually be a better approach, but that would mean calling PartyInfo twice or convincing it to supply two ropes sometimes or something. Worth thinking about; still not there yet on what Smartses need to know. November 26, 1985 4:09:21 pm PST Reason, comment should be part of credentials? Seems to need to be replicated, too. Sigh. November 26, 1985 4:09:21 pm PST Determine degree of authentication possible for each type of registrant. Add data structures necessary to reflect authenticated/not. Use RPC-provided information where possible to be sure of authentication. November 26, 1985 4:09:21 pm PST In any session, authentication of a GVNames cache password should be renewed by client call supplying password. Present interface can handle it, but it's not presently done. �Notes.txt Swinehart, February 23, 1987 6:57:29 am PST Copyright � 1985, 1986, 1987 by Xerox Corporation. All rights reserved. Vital August 12, 1986 9:10:27 pm PDT Thrush Need to arrange for the $deferanswer database entry to apply to call rejection -- don't reject for a while either; need a way to requeue that, too. And a way to combine the code for setting the database to default value. Finch March 28, 1986 2:16:59 pm PST Finch Ken pier found this bug: Finch code guaranteed to fail If not active, try to make it active. March 14, 1986 6:54:46 am PST Finch Finch, NamesGV, ... should use approach of VoiceDB to re-import stuff. Maybe a package to manage permanent connections? Option to poll. Built on that will be local/remote LoganBerry, and on that VoiceDB et al. Will be nice entree to conversion to LoganBerry. (NamesGV is all right. Uses hints plus the new optimized import approach.) November 27, 1985 2:43:50 pm PST Finch In Finch, the initialization procedures are not protected by monitors or anything. During rollback, more than one reason for starting/stopping Finch can cause trouble, which has been experienced at least once. April 27, 1986 8:23:39 pm PDT Finch Reporting of problems in conversation log is still pretty bad. March 14, 1986 6:53:46 am PST Finch Finch should catch WalnutDefs.Error and do something or other; happens when Walnut fails and can't read the message to see if we should read the database. Probably assume there's a voice ID and go on. Documentation needs November 26, 1985 4:31:13 pm PST Thrush Interface: Document meaning of ThParty.Enable carefully. Important November 26, 1985 4:09:21 pm PST Thrush Consider []= rather than [] = ; now all the parties and state to a conversation can be found by using the conversation as an attribute! The other searches are fast due to $Party attributes and so on. Sounds like a winner, but wait. September 29, 1986 9:02:58 am PDT Thrush Should be able to view dial tones, ringing, other locally-generated things in terms of (active) membership in conversations. To be $ringing in one converation, one is likely to be $active in a conversation with a "ringing service" party, which would then be implemented on one's own Etherphone. This makes B-V a more tractable thing, since this sort of thing is always happening. Getting things shut down is tricky. Finalization? May 1, 1986 10:26:02 am PDT Thrush Toy with notion that Finch/Lark can both be parties in a conversation, one slave to the other while the other exists (willing to track state changes). Eliminates the last need for stateMismatch, I think. Or doesn't. Anyhow, makes things easier when dealing with multiple rings and conference behavior. Makes counting more difficult. November 16, 1986 5:52:44 pm PST Thrush D. Terry's suggestion that Finch depend from Lark, rather than the other way around. Then Finch could get in and out without zapping conversations or requiring as hairy a Substitution thing. Would change the name next time anybody looked, so should be notified somehow, but notification is important on various things anyway. November 26, 1985 4:09:21 pm PST Thrush Smarts: Don't really go idle (goingIdle is OK) until all prose reports have been made (at least an error one) and like that. Exception: when communications are down, still have to deal with that. November 26, 1985 4:09:21 pm PST Finch Consider a way to get a busy test into Finch. Some Day December 8, 1985 4:51:20 pm PST Thrush Humph. At the smarts level, larkInfo knows about both smartses, so one could get associated parties that way when calling? Think it through; the redundancy of how trunks and telephones are found feels funny. April 30, 1986 11:42:07 am PDT Why does the intelnet-converted number show up anyway? Why doesn't that happen far enough downstream that nobody but the operating units see it? Probably so that the conversions from 6xxx to 9496xxx and so on will work. March 28, 1986 2:11:05 pm PST Finch, Thrush, VoiceDB, and the ideas therein could be used in other domains. Here are some examples of what I'm talking about: Finch: could support talker. Or at least a simple "send this string to this other Finch user" function. For use when you don't want to intrude, but do want rapid transmission. The phone could beep, if that bit could be got right. Could do the same with short recorded messages. They wouldn't be kept or have anything to do with GV. Only if the other party's got VoiceDB stuff running kind of thing. Could annotate documents with synthesized voice or just with other structured text. Could support refs in documents to unnamed but large and slow-changing things other than voice. Like figures for a paper, which are replicated in each version. And so on. January 28, 1986 6:18:12 pm PST Should/must mark the position of playback/recording within a message in more or less real time. Takes a different approach to communications with services. This is presently simulated by assuming that playback is continuous and linear. December 3, 1985 2:36:37 pm PST There's a problem with multicasting: once a lark is listening on a multicasting port, it can't be reached unless the multicast forwarder stays accurate. Over a server or forwarder crash, this isn't guaranteed. Polle points out that one approach is to use stable storage to record the current state of forwarding, being careful about synchronization. The multicast-forwarder would be responsible for keeping the state of multicasting tracking that of the stable storage representation. There would be a reset function that would communicate with each Lark, setting it back to normal, and clearing the related entries. For now, will be as careful as possible in the server code and hope for the best during conferences. November 26, 1985 4:09:21 pm PST Make stateInConv an ATOM, change tables into refTabs or refTabs of refTabs, stored in separate source files, registered to ATOMs (can change them on the fly). Use phone number mappings as model. Still haven't found a reasonable way to do this. �� voicelist&swinehart.pa#578564056�� Icode�+K��H�H�head2��block�M��M��M��M�� M��M��X�XM��M�fM��,�y9��M��M��\��M��!�bo�k��M��M��M��M�pM��!��bx��