Subject: nailing down transactions

From: Nancy-M Greene <[email-masked]>
Date: Wed, 1 Sep 1999 14:14:44 -0400

Brian, John,

The functionality creep since Berlin has been rather high. In order to get
some interoperability before the November IETF, we have to implement what
works and push off the extra features to version 2. So, let's clarify how
things work, instead of adding more, or reinventing things.

1) Stick to a simple policy for handling a failed transaction: you perform
all commands in order, in a transaction, until one (mandatory) command
fails. If a command fails, you terminate the transaction, performing no
other commands in that Action/Context, and start execution of no further
Action/Contexts in the transaction, and return responses for the commands
that succeeded within the Action/Context, and an error code for the command
that failed. Of course you also return responses for any Action/Contexts
that occurred in the transaction before this one.

Rollbacks or state changes as a result of a failure are an MG's actions that
can be audited and modified by the MGC as appropriate. There is no need to
add these into the semantics of a failed transaction.

Tom gave an example of when this is useful: you only want to apply a
call-waiting signal to a line if there is a call waiting - thus it is
logical to put the creation of the context for the waiting call in the same
transaction as the one that applies the call waiting signal.

2)  If you do not care whether a command fails or not, then you mark it as
optional (in ABNF, we proposed in an earlier msg to prefix a command with
O-, e.g. O-Modify).

Example 1: You send an Add to create a new context for a new call. In the
transaction you also put a Modify with the call display information. If the
Modify fails, you still want the Add to go ahead.

Example 2: Add * and O-AuditValue in one transaction. If the Add fails, i.e.
no terminations are added, the MG does not need to execute the AuditValue,
so it is marked as optional, and the MG would set the return code to
not-executed.

An optional command that is not executed is marked with the error code "not
executed". If the optional command fails, it contains the appropriate error
code. If it executes successfully, it returns the response parameters as
usual.

The difference between an optional command failing and a mandatory command
failing, is:
a) that the transaction continues to execute commands after a failed or
non-executed optional command, instead of stopping, and
b) it sends back a TransactionAccept instead of a TransactionReject.

3) A transaction groups together commands that need to be done together.
Thus, if the list of commands the MGC wants to do, do NOT need to be
performed together, they MUST not be put in the same transaction.

4) Handling errors when wildcarding is used: If the command that failed was
applied to many terminations we do not return the id of the termination that
failed. We assume the MGC will need to do an audit to find out the state of
things. In fact this brings out some problems in the current definition of
AuditValue - I address them in a different email. See also example 2 above.

Brian, John, Is this summary satisfactory? Let's get it into the draft then,
and move on.

Nancy

--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

---

From: Stephen Terrill <[email-masked]>
Date: Thu, 2 Sep 1999 10:32:56 +0200

Hi All,

This seems to be a reasonable proposal forwarded by Nancy.  The only addition/question I have is that for an optional command which fails, do we provide an appropriate indication in the transaction acknowledge.

Regards,

..//Steve