Subject: Re: Nits on the ABNF

From: Brian Rosen <[email-masked]>
Date: Mon, 13 Sep 1999 17:26:49 -0400

> Let is say that MG has these terminations, AAA, ABA, BAA,
> BBA, BBB, BAB,  and the MGC is only aware of ABA, AAA ,BBB, BAB,
> The MGC issues the following commands,
> Add B*  --> Add BBB, Add BBA, Add BAB, Add BAA, and
> Add *A  --> Add BBA, Add BAA Add ABA Add AAA.
>
> and it happens that Add BBA and Add BAA fail in each command.
> Unless you explicit say what has failed how the MGC can tell
> what had happened ???
Wildcards always return TerminationIDs.  That is not
the circumstance we are talking about.

The issue at hand was a failure in a command that
had a full TerminationID.  Should the MG return the
TerminationID.  I said no, you are arguing yes.  Need
an example.

Also, if the first add fails, the second one is not
executed.

>
> > > - Missing action reply in a transaction reply: fail the whole
> > > transaction?
> > > and MGC/MG sends message with error descriptor ="protocol error".
> > Can't fail it, it's the reply, not the request!
> > Need to send a reply (or a request, as above) with
> > the real error (missing action in transaction reply)
>
> First, you reply to the reply. I don't think we have this yet
> in MEGACO.
Yes, this is something we need to decide how to handle -
an error in a reply.  What do you do if the SENDER has
an error in the reply?  It has to, somehow, tell the
receiver that it had an error.  It probably doesn't matter
what you use.  I used reply because that is an obvious
flag to the receiver of big troubles.  Using a request
is not so obvious, since you don't get errors in a
request.

>Second, you have not described how the MGC
> should handle that case ! What Nancy meant by fail is the
> MGC considers the transaction as being failed, right Nancy ?
Not if the MG considers it to be complete!!!
That is the issue here - the MG thinks it did the
right thing, the MGC doesn't agree.  Whatever the MGC
decides to do, the MG has completed the transaction, with,
as far as it is concerned, no errors.

> Third, we dont have error with in a request but we have that
> with a top level error message. and that is what should be
> used because this a serious protocol violation and you need to
> be able to report that to the MG/MGC.
Don't agree.  You know the transactionID, the ContextID
and the command that failed.  You can tell the receiver
what you know.

I'll admit it's a pretty serious error, and probably anything we decide is
okay.

> > > - Missing command reply in an action: fail the transaction,
> > > and MGC/MG sends
> > > a message with error descriptor = "protocol error".
> > Same as above, can't fail, and can give a meaningful error
> > message.
>
> Same as above note.
Brian

---

From: Christian Groves <[email-masked]>
Date: Tue, 14 Sep 1999 14:43:35 +1000

G'Day,

To me it seems easier to have one rule for all instances - that is
return the termination ID . That way the MG and MC don't have to
remember or determine what to do, they always expect to send or receive
the termination ID.

Also the last statement it was mentioned that if the first command fails
the second is not executed. I was under the impression that optional
(o-) processing of commands was in. So this case could happen. Could
someone clarify this?

When a group of terminations is wildcarded it will potentially result in
a large number of responses from the MG and result in large messages.
Does the ABNF allow sending a '*' in the transaction accept when all
termination were accepted with the same response?

Cheers, Christian