Subject: Re: T13) Transactions - allowing optional commands

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 24 Aug 1999 02:04:57 -0400

The intent with our transaction-level ACKs was that these ACK messages would
also include echoes of the individual commands within the transaction,
providing data such as contextIDs, terminationIDs, and SDP which had not
been specified in the original command.

The action may be the appropriate level of acknowledgement, but I'll walk
through the call waiting example (actually in response to Natarajan
Kalpathy's earlier query) to demonstrate a dependency between two actions.
Basically, the steps in the call waiting scenario are these, which I could
claim each illustrates one transaction:

(1) A context C1 is set up to contain the parties A and B to the original
call.

(2) A context C2 is set up to contain the third party C; upon successful
completion of this step call waiting tone is applied to the called party A
and the MG is directed to watch for the link action on A.

(3) A notification is generated indicating that called party A has performed
the link action (e.g. hookflash).

(4) A is moved from context C1 to context C2.

Step (2) involves multiple commands and multiple contexts.  The ordering of
the command execution matters, in that there is no point signalling A if the
resources are not available to set up the new connection between A and C.  I
would argue that this illustrates why we created the transaction concept.

Fire away.

> -----Original Message-----
> From: Michael Thomas [SMTP:[email-masked]]
> Sent: Monday, August 23, 1999 7:55 PM
        [[TomT]]  ...
>    If ACK's are moved up to transaction level,
> won't that break use of SDP? Eg, if I had a
> transaction which did Add Term1, Add Term 2 (say
> for videophone), I'd expect to see two different
> SDP announcements, one per Add. Another thing to
> consider are command warnings like the digit map
> thing we discussed last week. The MGC might want
> to correlate which digit map failed, perhaps to
> install a simplified (but perhaps less optimized)
> digitmap.
>    Hong Liu also brought up the case of failures
> with wildcards, and how the MGC would learn of
> that. This points at the action level as being the
> least common denominator. In general, the MGC must
> be able to recover from errors in such a way that
> it exactly knows the MG state after the error.
> I'm somewhat dubious that audit is a cure-all here
> either -- errors are sometime transient, and audit
> only covers the things that it covers. If it's
> outside of the scope of audit, then the MGC must
> reset the MG to a well known state (perhaps
> through a ServiceChange).
>    Clearly the MGC doesn't want to be flooded with
> ACK's on every little piece of code that went OK,
> so maybe the right thing is to allow the protocol
> to return multiple status messages, perhaps even
> to the action level, but require the MG (SHOULD or
> MUST) to do message aggregation (eg, fold
> redundant 200's into a single 200 from action, to
> command, and perhaps to transaction).
>
>               Mike

---

From: David Oran <[email-masked]>
Date: Fri, 27 Aug 1999 10:12:41 -0400

Is anybody besides me shaking their head about how complicated we're making
this poor protocol? Are we going to wind up with 3 years of interoperabilty
workshops before a customer can be confident about interoperability (you all
know what protocol I'm refererring to here :-) ).

I think we should at least think about Christian's suggstion that we just go
back to individual atomic commands and pitch all the rest of the complexity,
or, as Mike Thomas suggested, punt such complicated stuff to scripts.

Dave.

> From: Media Gateway Control (megaco)
> [mailto:[email-masked]]On Behalf Of Tom-PT Taylor
> Sent: Tuesday, August 24, 1999 2:05 AM
> To: [email-masked]
> Subject: Re: T13) Transactions - allowing optional commands
>
>