Java Telephony API Version 1.1 Open Issues

  • Getting a Provider Object

      In JTAPI 1.1, the JtapiPeer class defines the point of contact between application and JTAPI implementation. However, access to this class in a Java client environment is not always easy to ensure short of installing the JtapiPeer instance on that client.

      Clearly, the JtapiPeer as presented in JTAPI 1.1 is not a general solution to the problem of giving all types of applications and applets access to a JTAPI Provider.

      A more general solution will be provided in the next release of JTAPI, while maintaining support for the existing JtapiPeer model. The current JtapiPeer class scheme is sufficient to support development of applications and implementations to JTAPI.

  • Document Detail
      The JTAPI 1.1 spec addresses two audiences, JTAPI application writers and JTAPI telephony server implementors. It must communicate information to both groups. In some instances, this results in excessive detail to one party or the other. In other instances, there seems to be no good way of communicating the detail required by one party. One particular instance of the latter problem is communicating the detailed semantics of Call.connect() to an implementation audience.

      Call.connect() can return a Connection, whose destination Addresses may not be identified by the same string as used in the Call.connect() to identify the destination. This could be the result of some switch idosynchrosy, for instance. In such a situation, the implementation must maintain 'aliases' for a particular address to present a consistent view of Address references to the application.

      This kind of detailed information, most often required by the JTAPI implementors is provided as much as possible in this specification. However, if any area of the spec is found ambiguous or lacking, please feel free to use the feedback section of this document to ask for more detailed assistance. Every reasonable effort will be made to address your questions.

  • Synchronization of Threads
      The JTAPI peer implementation can (and probably will) have its own threads of execution, separate from application threads. Thus, provisions must be made for synchronizing changes to the data structures which are shared between the application and the peer, that is, the call model objects. At the event observer level, the reports of individual changes to the call model are bundled together into indivisible meta-events. Peer updates to the call model are synchronized with delivery of these meta-events to the event observers. Thus, the observers always see the call model in an consistent state. No such synchronization is available in JTAPI 1.1 for non-observer application threads. Applications which examine the call model objects using methods such as getStatus() and getConnections() may receive inconsistent information, due to simultaneous changes to the objects by the peer.

    Java Telephony API Version 1.0 Issues (CLOSED)

  • Naming: There are numerous naming issues that we would like to resolve by JTAPI 1.1.
      There are numerous naming issues that we would like to resolve by JTAPI 1.1. We have chosen some abbreviations for event class names. We are abmivalent over the choice of 'Set' as the name for physical devices. In general, there may be some effort to improve naming by 1.1, at which point those choices will freeze.
  • Macro Events
      There are some sequence of events, which to an application might better be represented as a single event. This is particularly so for transfer and conference, which as sequences of events may be difficult to interpret by applications that may not have the full context needed to resolve those sequences.
  • Capabilities:
      A capabilities package is under construction. It allows applications to query whether they can place a telephone call, answer a telephone call, or drop a telephone call. We still need to do a fair amount of work here.
  • Package Structure:
      There remain some questions of package structure. Though much of the structure is agreed upon and settled, some subtle changes may take place. For instance, the java.telephony.callcenter package may become java.telephony.callcontrol.callcenter and some of the capabilities may migrate to be more closely associated with their associated packages.