Notes on Signaling Interface

26 February 1999

Updated 2 March 1999

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

26 Feb 1999

Notes from Friday, Feb. 26 meeting

1. Signaling uses a sequence number to keep track of which connection to be hung up when a Hangup packet comes in.
2. There will be a simple DesktopSignaling constructor that takes one argument (the SignalingObserver object, or "this"). In this case, DesktopSignaling will still register the user, for administrative purposes, using some generic UserID and application string. Added 3/2: the application also needs to pass in a username and password, so that DesktopSignaling can authenticate with Directory Services.  Our simplest constructor is now DesktopSignaling (SignalingObserver,String,String).
3. The DesktopSignaling.Dial() function will take a String rather than a UserID. This simplifies the API.
4. How does DesktopSignaling handle the timeout on waiting for START? (After timeout, DesktopSignaling invokes onAbort() on his SignalingObserver. As with HANGUP, DesktopSignaling closes the Connection via Connection.close(). Modified 3/2: instead of Connection, this will be a SigConnection, which contains the Connection object to be closed.
5. New decision: it will be the application who will be responsible for calling Connection.open() when its onStartCall() method being called. (Tuesday's notes had Signaling doing this.)
6. The Gateway driver will have one thread per telephone line, to wait for incoming calls. When a call comes in, a separate thread will handle it. Probably the array of Line objects should be Synchronized.
7. So far, there has been no change in the procedure that DesktopSignaling will use to determine where its peer DesktopSignaling is for a Dial(): Changed 3/2.

      Directory lookup on UserID returns a LocationList.  
        [ One decision on Friday: EVERY user of ITX telephony software
          must authenticate - once, at the beginning of the app - with
          Directory Services.  For Directory lookup on UserID, however,
          UserID could be the name of an application; it could be an
          anonymous application that doesn't need ever to be found.
          In this case, the LocationList could be to be VERY long. ]
      Extract the list of IPAdresses contained in this LocationList.
      Directory lookup on "signalingsrv" returns a LocationList.
        [ By lookup on "Signalingsrv" I mean find the Locations
          where UserID in Directory Services == "SignalingSrv" ]
      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.
        [ Who or what exactly is "our UserID"? ]
      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.
   

8. DesktopSignaling always waits for incoming packets. It can do this because it has one server thread waiting for incoming packets, while another thread is free to take calls from the application, e.g. Dial().
9. Also decided on Friday: There will be an extra parameter to be a custom object that is added to the INVITE and ACCEPT SigPackets. This allows an application to implement custom signaling.
10. There will be a management app (who will write?) that will let users authenticate them selves with directory services. I don't understand at all how this will work. Presumably if the user wants to run an application (like PanicButton), then that application will have to throw up a window through which the user can authenticate, before going on to run the application. We really need to work out some details here. That is what we did on March 2.
11. The question of directory cleanup is still open for discussion. There are two main alternatives: making persistent server applications issue periodic "still alive" events to Directory Services, or having a separate management program cycle through all the entries in Directory Services, pinging them as it goes.