ICEBERG Architectural Issues for Computer-Telephony Integration

Below, I have attempted to list the architectural issues in the design of an IP-core network for Computer-Telephony integration. Please send me feedback on or any additions to this list.

Note: I have based the description of these issues on the components of the initial Universal-Inbox model. This of course, could be wrong. But I think many of the issues would still remain with the functional components even with an alternate approach.

Issues with the Universal-Inbox Service

By Universal-Inbox Service, I mean the functional component that does the impedance matching between an existing network/device and the IP-core. This is roughly equivalent to the Iceberg Access Point that appears in the ICEBERG Architecture talks.

• How to structure the several Universal-Inbox services? That is, what is the big picture? What is the call set up procedure? What roles do the different Universal-Inbox services play in setting up a phone call?
• What is the interface between one Universal-Inbox service and another? What is the signaling protocol they talk between each other to set up a phone call?
• What are the persistent/soft state requirements for the Universal-Inbox service? What are the requirements that this service imposes on the Ninja infrastructure?

Issues with the Directory Service

By Directory Service (we need to come up with a more intuitive name for this - but until then, this name will stick), I mean the functional component that maintains the name mapping and the component that maintains user profiles and preferences to provide personalized communication management. One of the issues listed below is about whether the name mapping and profile/preference management be done by different components.

• How to structure the directory service? Should the user-profile management be separated from the name-mapping management?
• How will the different directory services be placed in the wide-area? How to locate the directory service that has the profile of the callee in a particular call?
• How will the directory service make use of information that is embedded in the components of specific networks? For example, reachability information in a cellular network or "line-busy" information from a PSTN network should be available to the directory service.
• What is the interface provided by the directory service? It needs to provide an interface for profile updates and profile lookups. It also needs to provide an interface for name mappings.
• What is the storage model for the user-profiles? (That is, what is the logical scheme?). This would involve defining what constitutes an entity that can own a profile. This would involve dealing with shared phones as well as with multiple roles a person can take (professor, advisor, friend...).
• What is the storage mechanism for the user-profiles? (That is, what is the physical scheme?). I think this is the part that is provided by a persistent hash-table or the XML database.

Issues with Data Path

• Is there a service (like Emre/Barbara's Network service) that does APC? What is its interface to the control protocol?
• Where do the operators run in the case of a call across the wide area?

Issues with Service Handoff

• Given all the above, how to do service handoff? To turn the question around, how should the above issues be solved to support Service Handoff?

Design Evaluation Criteria

• Should work with existing networks and end-devices (PSTN/GSM/Pager).
• Should accommodate more intelligent end-points (Smart phones or even full-fledged Desktops).
• Should work in the wide-area. Scalability and performance in the wide-area.
• Security issues (what are these?)

Strategy

• The 3-arrow model: Quick design, refine design iteratively. I don't think we should try to solve all these issues in the first iteration.
• To a first order, we should design for functionality. Performance issues come in the next iteration. (This is also the model that the Ninja people seem to be following).
• We need to come up with a plan for the semester soon (in the next "Integration Issues" meeting?)