(1) Feedback at the poster session:

This is feedback that I got from Timothy (Sprint) at the poster
session, after he looked at my "Service creation and extensibility in
Iceberg" poster. The question that he asked me was why such a thing is
not possible in the SS7 network (something that he alluded to during
the feedback session as well). SS7 network also allows service
creation, establishment of call-centers, extensibility, and so on. He
even mentioned a click-and-drop GUI that he had seen for creating
telephony services. (He promised to send me a pointer to this GUI;
I've asked him it).

Is the only case our service creation model that phone companies are
not friendly whereas the Internet is open? (This is also fine). Or,
are there any fundamental technical reasons why service creation is
hard in POTS?

On the "Security in Iceberg Call Setup" poster, the complaint was that
nothing existed in implementation. This needs to be worked on.

(2) Discussion of "Reiner's challenge" at the breakout session:

Initially, people seemed averse to discussing one particular telephony
service, for some reason. But we did get down to discussing it. Here's
what we discussed:

- Scenario: A is in call with B; C calls A
- Issue: Where to maintain the state that C had called A, so that when
  A or B hang up, a call is established between A and C
- The service is somewhat different in that such a state has to be
  maintained for a session (the session between A and B). This is
  session state in some sense.
- The first thing that came up was that we need a piece of state for
  A, as well as for C. This is because, if A decided not to have C
  called or keeps talking for long, and C is expecting the call, C may
  wish to be notified after some time (say, 2 hours).
- Like all other session state, can this state be maintained at the
  IAP? Can the list of people who called A, when A was talking with B,
  be maintained at A's IAP? This seems natural since the state is for
  a session.
- But this is not appropriate since the state should exists even if
  A's IAP or A's cell-phone dies (A could be called on another
  end-point). For the actual call session state, it does not matter if
  A's IAP or A's cell-phone dies. But for this session state, it does.
- Should state be a part of the PAC? Which is supposed to have dynamic
  personal state? It can maintain the list of callers who called A.
- The service could get complicated easily - preferences, maintaining
  the list of callers on arbitrary scenarios (A goes inside a cave, or
  equivalently, Soda, where there's no cell-phone coverage ;-).

Some random points that emerged from the discussion:

- Gunnar: A service being an end in itself vs. being a primitive for
  more complicated services (example - call forwarding could be
  thought of as a primitive for composing more complicated services)
- Gunnar: Building new services out of existing components vs. adding
  features to existing services (example - adding features to call
  forwarding versus using the basic call forwarding as a primitive in
  implementing a new service with the same additional functionality).
- Keep IAP call setup interface simple. Have an equivalent of IN
  trigger points? IN has trigger points in the basic call sequence, to
  implement new functionalities.
- John Barr: What about presence services? Can I know if my pal is
  ready to receive an instant-message on his cell-phone? Something
  like AOL instant-messaging.
- Use Jimmy's undergrad testbed to try these kind of new services.
- Maria Ebling: How to change preferences dynamically? That is, the
  system behaves in a certain way the first time. Can I tell the
  system not to do that the next time? Some sort of support for
  iterative refinement of the user preferences - which might be useful
  for the user?