Subject: Questions.2.1 - RESEND

From: [email-masked] (Lawrence Conroy)
Date: Mon, 30 Aug 1999 14:15:33 +0100

Hi All (again),
Herewith a couple of comments that seem to be simmering under the surface
of the SUB/NOT discussions. I'd like to see what we agree on before we go
on to the interesting bit.
------------
For the purposes of this discussion, I'll call the session started by a
SUB-scribe and ended by a BYE (or Scott's SUB with Expires=0 :) as an
"interest" session; it has to be better than calling it a "buddy" session.
----
I contend that a PINT Invitation is only the start of a service 'session'.

A service request defined by the PINT Invitation (INVITE//200/ACK) will be
delivered to a PINT Gateway and thence to the IN/GSTN, where it may be
executed.

At some point, the IN/GSTN will have either completed the service
invocation successfully, rejected it, or have been unable to complete the
request (such as might be the case if, for example, one of the GSTN parties
specified in the service request was unavailable). This constitutes the end
bound of the service 'session' that starts with the initial PINT
Invitation.

>From the perspective of the IN Service Control Function (SCF) to which the
PINT Gateway is connected, its involvement in a service requested might
extend only as far as setting up a service call, or to its completion.
Thus, the duration of the service 'session' that results from an initial
PINT Invitation may differ, depending on IN/GSTN internal design.

The service invocation (i.e. the service request received by the Service
Control Function) and, indeed, any service call that results can be
identified using the same information as was used in the original PINT
Invitation that triggered these actions; the Gateway will have all
necessary data to correlate the Invitation with the IN/GSTN portion of the
session.
----
Information may be available at the Gateway regarding the ongoing status of
the service request and/or the disposition of that request.

In practice, the Gateway may receive a large number of requests, and so it
may have a finite capacity to store this disposition information. As a
result, there may be a time limit beyond which this information on a past
service request is expunged.

----

With PINT, a node may "register an interest" in the status or disposition
of a service request. The effect of this is to open a new session between
the interested node and the Gateway, during which the Gateway may return
information on the status and/or the disposition of the associated service
request.

This "interest" session is tied to a particular service 'session'. There
may, in principle, be a number of different "interest" sessions active at
any one time for a single service 'session'; each of these "interest"
sessions is discrete.

An "interest" session may be started by the node that originated the
service request, OR by a third party. It may be started by the INVITEr, but
with a Contact: header indicating that any further information be sent to a
third party. In principle, it could even be started by a third party, but
with a Contact: header indicating that subsequent information be passed
back to the orignal INVITEr.

When requesting the start of an "interest" session, the message must
include a correlator to show the identity of the service 'session' of
interest.

When asking for the termination of an "interest" session, the message must
include an identifier to show which "interest" session it to be closed.

Any disagreements on this, so far?

All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

---------
This message came from the IETF PINT Working Group Mailing List.