Subject: Re: T13) Transactions - allowing optional commands

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Aug 1999 11:16:52 -0400

> 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

---

From: John Segers <[email-masked]>
Date: Mon, 16 Aug 1999 17:40:33 +0200

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

--
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: Stephen Terrill <[email-masked]>
Date: Mon, 16 Aug 1999 18:26:42 +0200

Hi,

> anywhere near enough to do any detection on, so what is the

It might, but I understood that some transactions could take a long time (otherwise there wasn´t the need for the transaction pending indication from the MG to the MGC).  The command taking the "time" might be the command which fails.

> at the Megaco protocol level is completed.

If there was not the possbility of failure of a release message, then there wouldn´t be the supervison functions on the release message that exist in PNNI, B-ISUP, Q.AAL2 (Q.2630.1).

This can also be considered to the "add" case, if there are two "adds" in the one command pertaining to bearer control protocols.  If the first one was successful, and the second one failed, releasing the first one will not undo the "statistics" of the media gateway, nor the "business arrangement" issues or renting transmission resources.