Subject: Re: T13) Transactions - allowing optional commands

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Aug 1999 12:04:13 -0400

We are not communicating.

The UNDO method keeps sufficient state to restore the
terminations.  This implies some quarantine of resources.
I believe the only thing that won't work is bearers that
are connection oriented with hard state (like ATM).

The 2 pass method says if you encounter a subtract, you
check the parameters carefully, do not do the actual release
of resources, and keep checking.

When you get to the end of the transaction, go through and
complete all the processing, with the confidence that no
further errors should occur, and if they do, there are very
serious issues that just getting the command matched with the
error isn't going to help.

If you need a provisional response, and you are really worried
about signal production, then use the 2 pass method.  I actually
don't think there will be a real problem with the undo mechanism,
even with provisional response.

Brian

Brian

> -----Original Message-----
> From: John Segers [mailto:[email-masked]]
> Sent: Monday, August 16, 1999 11:41 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: T13) Transactions - allowing optional commands
>
>
> Brian,
>
> The problem is not in checking the parameters of the SUBTRACT message.
> A later command in the same transaction may fail.  This could be any
> command, that may fail for any reason.  It could for instance
> be an Add
> command that fails because a line card fails.  Then the
> SUBTRACT has to
> be undone.
>
> And there must be transactions take longer than a couple of
> milliseconds
> to execute.  If there aren't, why do we need provisional responses?
>
> John
>
> Brian Rosen wrote:
> >
> > > I think that in addition to considering that the tone could
> > > be sent to a subscriber, one should consider that the tone
> > > could be a DTMF tone sent to specialized equipment (IN
> > > service with DTMF reception, a bank etc).  The MGC should be
> > > aware of what was sent and what wasn't sent.
> > But you would only get a sample or two of the tone out, not
> > anywhere near enough to do any detection on, so what is the
> > problem?
> >
> > > In addtion to that, there is the scenarios where the bearer
> > > control (e.g. PNNI for ATM) is in the media gateway, and the
> > > subtraction of a termination will result in a release of the
> > > resources.  This cannot be "un-released" (those resources may
> > > already be re-used in the network immediately).
> > I don't believe there are any errors that are possible on
> > a RELEASE message except parameter checking types of messages,
> > and the handling of those is beyond the protocol.  If you
> > verify the correctness of the parameters to the subtract, you
> > can delay the actual release until all other error checking
> > at the Megaco protocol level is completed.
> >
> > > I think that these concepts lead to the need for the
> > > optionality in the commands and/or the ability to be able to
> > > indicate where the command processing stopped.
> > I disagree
> >
> > Brian
>
> --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 344
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 17 Aug 1999 17:12:34 -0700

> error isn't going to help.

   Here I just disagree with your analysis. All
that can be checked up front are static kinds of
things like parsing errors and the like. The MG
cannot, however, predict that an SVC or RSVP
request will fail until it tries to execute it. In
order to support this, the MG would need to not
release any resources before it completes the
current transaction. This can lead to deadlock
issues when resources are tight.
   It seems that you are asking for a transaction
rollback model akin to what RDBM's do. If so, I
think that puts undue complexity into the MG which
I think is much more simply handled in the MGC.
Is there some compelling need in the MGC's to
force the MG to implement rollback? I haven't seen
such a need with MGCP.

                Mike

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Aug 1999 18:56:17 +1000

I agree with Mike here. I'm also alittle worried about you mentioning
that ATM bearers won't work here. Last time I checked in the
requirements and the protocol document, Megaco/H248 was valid for ATM as
well. Therefore I think we need to a solution to handle both IP and ATM
bearers.

That's is : no rollback and let the MC decide what to do in an error
case.

Cheers, Christian