<> <> <> <> <> incoming: disconnect without answer, caller gave up. outgoing: we gave up, before/after dialing. Prefer fixed-pitch font, so that bold-face doesn't change occupied field width. Possibly, "at home" <> <> <> <> <> <> <> <> <> <> <> July 16, 1987 9:57:55 am PDT Finch Nits in connection with new error/connection management code Disconnect report produces strange conversation empty log selection. Finch properly reports conversations in progress on reconnect, but when you terminate one, it doesn't get its selections right, leaving the in-progress one selected, adding a new one and reporting it as abandoned. Conversation log reports are not well-handled. No attempt to relate conversation log entry before last disconnect to conversations reported after next reconnect. Should be enabled/connected status fields maintained in Finch viewer somewhere, and three icons representing the three valid states: [disabled, disconnected], [enabled, disconnected], [enabled, connected]. Need to add Lark-running indication, too. Consider reporting of system state at CheckIn time. Should be an icon representing off-hook/dialing state. Still need changes to CheckIn to include informational messages (and a way to issue them.) Finch complain (text messages) too much in some places, too little in others (nb analysis). When a new connection has been made, we also reregister. This changes the valid local partyID and smartsID. On a retry, those have to be used. Actually, many of the original calls could leave these out, since we have to put them in anyway. July 15, 1987 10:36:04 am PDT Finch Use of conversation log to redial; other conversation log stuff Must retain, independent of cDesc, enough information with each log entry to redial by name, and to know if a later reported conversation either (a) is really the same conversation as one we have already displayeddue to crashes or network problems that caused disconnection, or (b) can replace a trivial one that we already displayedthe current off-hook-but-no-call-ever-placed situation. Enough might be name of other party(s?), max state reached (still a puzzle), conversation ID. Need to decide what to do about multiple-party calls, visitor reports, . . . still favor TiogaButtons replacement of existing thing. April 17, 1987 11:54:50 am PDT, December 23, 1986 3:49:42 pm PST July 30, 1987 6:10:56 pm PDT (fixed, but a cleanup pass is needed) Finch Identification of callers and callees in Finch tool. Finch never looks at the intendedParty field of the partyInfo, so it can't possibly get its to/from reports right. But even so, the name fields as set by ThPartyPrivate.DoDescribeParty seem questionable, at least in visiting cases. Suppose Strowger is visiting PolleZ, and Strowger gets an outside call. The calling party's name field shows up at PolleZ's Finch as "Strowger.lark (outside line)". You'd like to report "Call to Strowger.lark (via PolleZ's party's intendedName field) from outside line (via the calling party's name field)". If PolleZ gets an outside call in the same situation, the calling party's name field shows up at PolleZ's Finch as "PolleZ.pa (outside line)". (Polle) <> <> December 19, 1986 1:45:04 pm PST, July 30, 1987 6:11:22 pm PDT Finch Need for better name depiction in Finch. indicate real names of people, rather than RNames, in Finch log. Real names on screen, both names in permanent log? Need a general cleanup of naming and phone number management. February 2, 1987 10:55:34 am PST All LarkOn state indicator in Finch needed. 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. <> July 30, 1987 11:08:04 am PDT ThParty.PartyInfo provides: name and intendedName own and intended PartyID type, enabledness voicePath: TRUE if party or its poachee has a voice path. other indicators of activity. via ConvInfo, various conversation attributes, along with party ID of originator. <> <> <> << CLog: Compare name and intendedName to determine whether to name both parties.>> << CLog: In OtherParty (the workhorse), use intendedName, use type to determine authenticity ("?" for $telephone).>> <<>> <<>> <<>> ThParty.NameReq: TYPE = ATOM; -- { $owner, $current, $description, $address, $none }; <<$owner: RName of creator of this party;>> <> <> <> <<$current: Current assignment;>> <> <> <<$address:>> <> <> <<$description: dolled-up version of $current, suitable for framing, including all known names and numbers, for Finch and so on.>> <<>> << Telephone Trunk Individual Service>> <> <> <> << 941539212344>> << outside line5>> << ABC (outside line)6>> <

> << PolleZ.pa7>> << NIL7>> <> <<>> <> <<1. The name used to identify an outside party, either just descriptive or the key in a database query.>> <<2. The outside party phone number for outgoing calls: see number analysis>> <<3. Both description and number are known.>> <<4. Number was supplied without description.>> <<5. Incoming call.>> <<6. Incoming call following outgoing call in which a description was supplied.
Bug?>> <<7. Describe[poachee, $address] if there is a poachee, else NIL.>> <<8. Most recent individual to reserve this service party.>> ThParty.GetPartyInfo[...nameReq] produces PartyInfos, either just one or descrs for all parties. <> <> <> <> ThParty.DescribeParty[...nameReq] returns: name: based on nameReq. type partner (poacher or poachee) visitee (if any), visitors (a list, if any) <> <> <> <> <> <> ThParty.GetNumbersForRName provides a laundered access to the NameDB white pages, returning only full RName, one office number, one home number. Should probably go away, in favor of direct consultation through NameDB. <> ThSmartsPrivate.DBInfo[] packages up a number of NameDB and DescribeParty calls, and does some other rName processing. <> <> ThPartyPrivate.MakeServiceRname: PROC[serviceName: Thrush.ROPE] RETURNS [serviceRname: Thrush.ROPE, serviceRnameAtom: ATOM]; <.Lark", as a ROPE and as a corresponding ATOM. Permits lookup of service attributes in NameDB database, and representation of service in Triples database.
Please repair comment in ThPartyPrivate.>> <<>> ThPartyPrivate.DoDescribeParty[party, nameReq] => name. <> <> <> <> ThPartyPrivate.GetRnameFromParty[party, nameReq] => rName, atom <> <> <> <> <> <> <> <| . ]*;>> <digits, retains but ignores punctuation.>> <> <<3-4 digit Centrex numbers (if beginning with 9, they're really local CO numbers)>> <<5 digit 7xxxx numbers => 9408737xxxx (Sunnyvale)>> <<7-digit local CO numbers (leading 9 will be supplied)>> <<8-digit local CO numbers, beginning with 9, or Intelnet numbers, beginning with 8>> <<10-digit DDD numbers (leading level (8 or 9) will be supplied)>> <<11-digit DDD numbers, (explicitly including leading digit).>> <<9011...., any length; international calls.>> <<>> < or '. . The number should have one of the forms, modulo punctuation, described just below.>> <> <<8*yyy-xxxx (Intelnet numbers)>> <<8*nnn-yyy-xxxx (DDD numbers, to be dialed via Intelnet, outside the region)>> <<9(nnn)yyy-xxxx (DDD numbers nearby (Intelnet won't work), for non-Intelnet users)>> <<9-011-xyzwabcde (International numbers; not usually dialed via Intelnet.)>> <> <<>> <> <> <<>> <> <> <> <> <> <> <> <> <> < rope: converts letters to digits, leaves punctuation in place.>> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <<>> <> <> <> <> <> <> <> < ThParty.GetPartyFromFeepNum,>> < ThParty.GetPartyFromNumber,>> <> <> <> <> <> <> <> < ThParty.GetPartyFromFeepNum,>> < ThParty.GetPartyFromNumber,>> <> <<>> <> 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). <> <> July 19, 1987 9:09:12 pm PDT Finch Separate TDir command, to feed a once-only directory to Finch? June 17, 1987 4:56:59 pm PDT Bluejay Recording a voice rope that is only silence doesn't seem to work, even yet. Doesn't stop when you tell it to, and subsequent requests don't work right, either. Or yields 0-chirp tune and 0-length voice rope. In addition, there's no good handling of the situation where the Jukebox is, or thinks it is, out of chirps. You just get a one or two chirp tune with the chirps missing. June 18, 1987 7:23:40 pm PDT Thrush/All Should reorganize PartyInfo so that the non-conversation related stuff is first. Then change Describe Party to return a single PartyInfo record. The name and such is in there, along with other useful stuff; like the type and whether there's a voice connection. June 18, 1987 7:24:28 pm PDT Thrush/All Think soon about various queries that might be applied by Finch to find out about things. June 18, 1987 7:24:49 pm PDT Finch/All Find a way to register important public conversations, along with access lists and such. For meetings. Possibly add a telephone-driven user interface to start one, so that there needn't be a workstation in the commons; the index identifies a standard conversation name. June 18, 1987 7:25:57 pm PDT New Consider finding some hack way to connect ARK to the Etherphone. Far blazing out! June 12, 1987 2:56:39 pm PDT Bluejay 7. Bluejay should time out $active with only one party in a manner similar to $trunk. Possibly $telephone should too, but that's less clear, due to hold and such. June 9, 1987 3:22:20 pm PDT Thrush Do the initiating/notified 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. June 5, 1987 5:00:54 pm PDT Thrush LarkTrunkSmarts needs timeout protection in initiating and pending states (maybe just the former), similar to LarkSmartsSupImpl. Or maybe not. Wait and see. 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. This can be deferred until after release, probably. 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. 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? <[]= 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.>> 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. 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. (Sliders?) 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. <> <> <> July 20, 1987 5:06:33 pm PDT Finch Beep or something to announce an intercom (autoanswer) call? July 19, 1987 9:06:11 pm PDT Thrush Set "ApplicationState" in LarkControl at Party-to-LarkSmarts checkin time. Should only repost when things have really changed, though. Should also find a way to post unknown state when a timeout has occurred, and that's hard. June 6, 1987 6:37:09 pm PDT Thrush Report Limits exceeded happens at times when we're reporting debugging stuff intentionally, and it shouldn't. Somehow it should be makeable bigger at times. Look at it again sometime. For now, just go in and reset the enabled value by hand in VoiceUtilsImpl.pd. May 15, 1987 5:51:05 pm PDT Thrush DBInfo, or maybe something at the LoganBerry level, should operate at least a one-element cache at the entry level. 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. <> 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 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.