Notes from Tuesday, Feb. 23 meeting

(http://www.cs.cornell.edu/cnrg/telephony/JavaDocs/notes.23feb99.html)

1. For our boom demos, we've got SPOT. Probably will have Voice Mail. Would be nice to have conferencing, but we haven't even thought about that.
2. Wilson has bind running as a primary and a backup. Will be starting implementation this week and next.
3. Data Exchange has STATS working.
4. A Connection will NOT have an ID in it. Instead, Signaling will have some sort of random number associated with each 3-way exchange. [changed. see 2/26/99]
5. Two more overloadings for the Dial() method are proposed (int is the optional timeout in seconds for between INVITE and ACCEPT):

           Dial (String, Channel in, Channel out)
   	Dial (String, Channel in, Channel out, int)
   

6. SignalingObserver should have yet another handler: on_abort() This one is called when your DesktopSignaling has sent an ACCEPT but then never received the corresponding START. DesktopSignaling handles the timeout on waiting for the START (how? TBD), closes the Connection via Connection.close(), and invokes on_abort().
7. Signaling will call Connection.open() after an ACCEPT packet [ changed. see 2/26/99], and Connection.close() on DesktopSignaling.Hangup(). SignalingObserver's onHangup() handler should call Connection.close() as well. What if the application wants to hand off an unopened Connection to a child? Is that a problem? [solved by 2/26/99 change]
8. Should PBXSignaling be able to run on a different computer from the Gateway? YES! Should gtwy.DesktopSignaling and PBXSignaling be considered to be one? YES! Rather than PBXSignaling having its own version of DesktopSignaling, only the one running on vada is used. This means that the gateway server has pretty much the same API as any other application. This is fully general: which gateway a PBXSignaling server is using at any time might change during the course of the day, depending on how many gateways we have. (Details yet to be worked out.) And if we have more than one PBX machines, they may be using the same gateway machine or separate gateway machines.
9. Here is how DesktopSignaling when carrying out a Dial can determine where its peer DesktopSignaling is:

      Directory lookup on UserID returns a LocationList.  
      Extract the list of IPAdresses contained in this LocationList.
      [ WAS: Invoke SignalingObserver.chooseUser() to pick one ]
      Directory lookup on "signalingsrv" returns a LocationList.
      Extract the list of IPAdresses containing in this LocationList.
      Merge the 2 lists to get the LocationList of DesktopSignaling objects
         our UserID might be using to receive the call.
      INVITE on each Location in turn until you get an ACCEPT; now you know
         where your peer is.
      If you run out of Locations, just return null Connection to app.
      If you get a BUSY packet (see below) go on to the next location.
   

10. There should be a 3rd kind of SigPacket to go along with ACCEPT and REJECT, something like BUSY. It is not quite the same thing as REJECT, because DesktopSignaling with BUSY will proceed down its LocationList for the next location to send an INVITE packet to.
11. TBD: How does a DesktopSignaling know to start up waiting on an input signaling port (as Gateway and Voice Mail do) or to return control immediately to the application (which PanicButton does)??? Should there be a DesktopSignaling.listen() method? [no longer an issue; see 2/26/99 about how DesktopSignaling has a separate thread to listen for input events.  If the application wants to make the first move, that's fine.]