Scenario Descriptions

Below is a description of a set of scenarios that illustrate the functionalities that we want to have in ICEBERG (notes from a couple of brainstorming sessions). A bunch of design issues that come up from the description are also listed.

Notes from Feb 19 1999

Definitions

An attempt at nailing down what we are talking about: some definitions so that what follows is easier to read.

Iceberg Access Point (IAP)

This is the component that does the impedence matching between traditional existing networks and the ICEBERG IP-Core Network. For example, an IAP sits in front of a H.323 gateway and makes it possible for analog POTS phones to access ICEBERG services.

In case the end-point is intelligent (e.g. PC/laptop), we can think the IAP as a module (process) on the end-point.

Entities

ICEBERG entities are users or services that have a single identity in real life. People can be entities (Bhaskar, for e.g.) as well as services (for e.g. a newscast internet service, or a company's repair service center).

As far as ICEBERG is concerned, an entity can be named and has a service profile (preferences for call handling). An entity can be reached by many means and preferred way of reaching the entity is determined on a per-call basis by consulting the entity's preference profile.

Preference Registry

This is a distributed repository that stores the preferences of ICEBERG entities. It is called a registry and not a database since it is a mostly read-only repository and since availability is more of a requirement than strict consistency.

Preference profile

This is the specification of preferences for a particular entity.

Unique Name (of an entity)

Each entity has a unique name (or unique-id) to identify it. How to name entities is an issue to be resolved. The unique-name of an entity is what is used to key the preference registry.

Network specific id

This is the id that identifies an end-point in a specific network. Examples include: POTS telephone number (+1-510-642-9076), Pager Number, E-mail address, IP-Address of desktop.

Name mapping

This is the process of getting a network specific id given the unique-id of an entity. For example, getting the pager number of an entity constitutes name mapping.

It is not clear if this mapping should be done by the same service that implements the preference profile lookup. It is possible to do both the name mapping and the preference profile lookup at the same place since both are keyed by the unique-id of entities.

Reverse Name mapping

This is process of getting the unique-id given a network specific id. For example, if the caller dials +1-510-642-9076, we'd like to resolve it to the unique-id of the entity to which the phone belongs. We may need to do this to subsequently lookup the entity's preference profile and appropriately handle the call.

It looks like we really need a distributed service that does both name mapping as well as reverse name mapping. X.500 seems to provide the solution. More thoughts on this to come later

All scenario descriptions are with respect to the following figure.

Scenario 1

This scenario describes a call from a cell-phone to a PSTN handset. For this scenario, the handset number is 642-8778 and the cell-phone is 555-1212.

1. Cell-Phone dials 642-8778 on the keypad.
2. An SS7 Call-Setup message goes from Cell-Phone to UPSim.
3. This Call-Setup message is relayed to IAP1 as an IP packet.
4. Now, IAP1 has to access the preferences of the entity owning the number 642-8778. For this, it first contacts the Reverse Name Mapping Service to get the unique-id of the callee entity. IAP1 --> Reverse Name Mapping Service "What is the unique id of 642-8778?". Issue: How to find which Reverse Name Mapping Service to contact? This is the problem of distributing the Reverse Name Mapping Service.
5. Response from Reverse Name Mapping Server --> IAP1 "bhaskar@cs.berkeley.edu is the unique-id of 642-8778". Issue: How to name entities? What do unique-ids look like? Right now, I've assumed that they look like e-mail ids. That way, we can use a DNS-like mechanism to locate the preference registry server given the unique-id (just like you get the mail server given the e-mail address).
6. IAP1 --> Preference Registry Server "Give me the preferred end-point of bhaskar@cs.berkeley.edu". Issue: How to locate the Preference Registry Server that has the preference profile of bhaskar@cs.berkeley.edu? The current proposed mechanism is to use a DNS MX-record like mechanism to do the location.
7. Response from Preference Registry Server: "The current preferred end-point of bhaskar@cs.berkeley.edu is 642-8778. Reach through IAP2". Issue1: How to store the preferences? The current status on this issue is that the preference profile of an entity should be an executable script with if/else statements. It should be possible to design a very restricted script that is safe to execute. Issue2: What if there are multiple IAPs through which the PSTN can be reached? How do you decide which IAP to use for 642-8778? Area-code?
8. IAP1 now talks the Iceberg Signaling Protocol to IAP2. IAP1 --> IAP2 Call-Setup message. Issue: What is the signaling protocol that should be used? The current consensus is that we use a stripped down version of SIP that we can implement easily.
9. IAP2 relays the Call-Setup message, the H.323 version, to the H.323 gateway. The called number is specified as 642-8778.
10. The H.323 gateway sends an SS7 call-setup message through the PSTN switches and the handset rings.
11. Bhaskar picks up handset.
12. PSTN sends the H.323 gateway a Call-Established SS7 message
13. Call-Established message --> IAP2 --> IAP1 --> UPSim --> Cell-Phone

The above steps do not say anything about the data path. Here's how that happens.

1. When IAP1 sends IAP2 the Call-Setup message, it also sends the Cell-Phone's media capability description. Issue: What format to use for media description. Well, we're going to have to use some media description for path creation. It would make sense to use the same format here as well. In the current standing, that would be an XML description
2. When IAP2 sends Call-Established message to IAP1, it sends the media description of the handset.
3. Issue: Now, who does the automatic path creation (APC)? IAP1 or IAP2? Since there's seems to be no reason to choose either way, let's assume that the callee end (IAP2) does it.
4. IAP2 sends caller and callee media descriptions to the APC service. Issue: How to locate the APC service? Where does it run? Presumably, the APC runs on iSpace/MultiSpace in a NOW cluster and you can find it using the Service Discovery Service (SDS)
5. The APC service finds out what operators can do the job and instantiates the operators. Note that two paths have to be created - one for each direction of communication
6. IAP2 returns IAP1 information about the last operator (at IAP1's end) of both the paths. This is basically a connector specification.
7. IAP1 starts sending data to and receiving data from the appropriate operators of the two paths. IAP2 does the same.
8. Note that in the previous step, IAP1 and IAP2 need not be directly in the data path. They may just instruct another component of the system to send the data stream. For example, IAP1 may tell the IP-PAD (the machine that gets the bits from the Base-Station and throws them out as IP-Packets, not shown in figure 1) to send RTP packets to the first operator in the forward path.

The call termination procedure is really simple. Either end hangs up. Call terminate message propagates from one end to another (with appropriate protocol conversions). IAP2 asks the APC service to destroy the path created.

Scenario 2

Same scenario as above but assume that 642-8778 is busy. Here's what happens.

1. The steps are the same as in scenario 1 upto the point where the call-setup message goes into PSTN.
2. Now, the H.323 gateway gets a Busy message from PSTN which goes to IAP2 and then to IAP1.
3. Now, IAP1 queries the Preference Registry Server again. This time it also gives the current call state - which is "642-8778 busy". This goes as additional input to the preference script. Now, the preference script decides that the preferred end-point of bhaskar@cs.berkeley.edu is the Voice-Mail Box reachable through IAP4. Note that this is not the PSTN Voice-Mail. This Voice-Mail is an internet service. You can think of it as a program which dumps the incoming audio onto a file instead of to /dev/audio.
4. IAP1 sets up a call with IAP4. There's no difference from scenario 1 in the rest of the steps

Scenario 3

Same as scenario 2 except that Bhaskar's preferences say that the call should now go to the E-mail store. Yet another small difference is that the path creation procedure gets a different input: GSM-Codec --> Text. The rest is all the same. (Is'nt it cool? APC is your friend).

Notes from Feb 22 1999

Scenario 4

Service Handoff. The situation is same as scenario 1. In the middle of the call, Helen with the Cell-Phone walks into 473 Soda. Now, she wants to continue talking on her desktop luge.cs which connects to the IP-Core through IAP3. The sequence of steps are as below.

1. After walking into 473 Soda, Helen presses the digits 4, 7, 3 on the cell-phone.
2. The DTMF messages are caught by the UPSim and passed onto IAP1 as IP-Packets.
3. Issue: Does IAP1 pass on the DTMF messages to IAP2 or initiate the handoff itself? What sequence of DTMF messages does either IAP interpret as an indication of handoff? The DTMF tones could be input to a legacy IVR application at the IAP2 end. Until we think through this issue, we assume that IAP1 interprets a sequence of digits with delimiters at beginning and end (say, the # sign) as an indication of request for handoff.
4. IAP1 interprets 473 as some sort of identity of where the call should be transferred.
5. IAP1 contacts the Reverse Name Mapping Service to find out the unique-id of the caller 555-1212 (actually, its a little more subtle in our current testbed; the UPSim we have cant get the number, we can only get the IMSI). The unique-id returned is helenjw@cs.berkeley.edu
6. Now, IAP1 contacts the preference registry server for helenjw@cs.berkeley.edu to find out the preferred end-point given the call-state (which is: call established to 642-8778; DTMF tones 4,7,3 pressed).
7. The preferred end-point returned is luge.cs reachable through IAP3 (which would most probably be co-resident with luge.cs since luge.cs is a desktop)
8. Now, IAP1, IAP2 and IAP3 have to exchange a set of messages so that finally: IAP3 builds the state for the call, IAP2 changes state to reflect the change in end-point and IAP1 cleans-up all state.

The state maintained at IAP1 is:

caller-id = +1-510-555-1212
caller-unique-id = helenjw@cs.berkeley.edu
callee-id = +1-510-642-8778
callee-unique-id = bhaskar@cs.berkeley.edu
callee-iap = IAP2
data-stream-state = first operator in the forward & reverse path
current-call-state = active

The state at IAP2 is similar. In addition, it also has:

APC service specific state = An id for each path created by the APC?

Issue: What is the set of messages exchanged between the three IAPs to cause the change of state? What are the failure cases that have to be handled in such a protocol?

Issue: How does the data-stream change? This is a dynamic-path issue. Can we just kill the old path and create a new one? It looks like you have to do this anyway if the handoff is from the IAP2 end (that is, the callee, where the path-creation took place originally).