Subject: [Megaco] processing order, errors, & wildcards

From: Troy Cauble <[email-masked]>
Date: Tue, 01 Mar 2005 14:34:19 -0500

Hi all,

I'm having trouble reconciling these specs for ordered processing
and for wildcards.  Section 8 of H.248.1 says:

> Transactions guarantee ordered Command processing. That is, Commands 
> within a Transaction are executed sequentially. Ordering of 
> Transactions is NOT guaranteed; transactions may be executed in any 
> order, or simultaneously. 
 >
> At the first failing Command in a Transaction, processing of the
> remaining Commands in that Transaction stops. If a command contains a
> wildcarded TerminationID, the command is attempted with each of the
> actual TerminationIDs matching the wildcard. A response within the
> TransactionReply is included for each matching TerminationID, even if
> one or more instances generated an error. If any TerminationID
> matching a wildcard results in an error when executed, any commands
> following the wildcarded command are not attempted.

In the first paragraph, "Commands within a Transaction are executed
sequentially" is very straightforward and would seem to apply
regardless of wildcards.

The second paragraph seems to reinforce that a command is executed
on all matching terminations moving to the next command.  But this
only *explicitly* refers to wildcarded terminations.

Section 6.3 of the IG says:

> When executing a transaction that contains wildcarded contexts and
> optionally terminations, all commands in the transaction are executed
> in order for a particular instance of ContextID before moving to a
> subsequent ContextID instance. In the case that there are multiple
> commands in a transaction, only when the TerminationID (wildcarded or
> specific) specified in the first command matches a specific instance
> of a ContextID are subsequent commands in the transaction executed.
> If a TerminationID (wildcarded or specific) of the subsequent
> command/s in that transaction does not much the specific ContextID
> instance then an error code 431 is returned and processing of
> subsequent instances of the wildcard ContextID are stopped unless the
> command that generated the error is marked optional.

While this section is explicitly addressing wildcarded Contexts, it
specifies a behavior that is, IMO, against the letter and spirit
of the earlier quote from section 8.

Can anyone reconcile the above items??

Related questions:

In my first quote above from section 8, it says: "At the first
failing Command in a Transaction, ...".

What is a failing Command?
Does failing on a Descriptor for a Command mean you failed the
Command?

If so, I would conclude that other Descriptor's within the Command
should not be attempted, based on the following, also from section 8:

> If a command fails, the MG shall, as far as possible, restore the 
> state that existed prior to the attempted execution of the command
> before continuing with command processing.

But this could be clearer.

Also...
In December we had a thread about whether the order of descriptors
in a response should match that of a request.  It seemed necessary
to add this requirement to distinguish what descriptor and error
descriptor referred to.

http://www1.ietf.org/mail-archive/web/megaco/current/msg05442.html

But given the requirement to "restore state", it seems inappropriate
to return successful descriptors in the restored cases.  This
leads to a command request with multiple descriptors being
answered by a command response with (as little as) a single error
descriptor and no way to know which descriptor was the problem.

-troy

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 3 Mar 2005 21:03:15 -0500

Sorry for the delay in answering.  I have been busy at the Q3 meeting in
Melbourne and wanted to spend some time thinking about your queries in depth
before answering.

The thing to remember with wildcarded ContextIDs is that it is a shorthanded
way of compressing multiple actions into a single action.  So, the following
transaction:

T=1{C=*{MF=T1/*{etc},MF=T2/*{etc}}}

Is really the same as:

T=1{C=1{MF=T1/*{etc},MF=T2/*{etc}},C=2{MF=T1/*{etc},MF=T2/*{etc}},etc}

So, by executing all the commands in order for a particular ContextID prior
to moving to the next ContextID, the ordering of commands is maintained.

Additional queries answered inline. [KJBII]

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Troy Cauble
Sent: Wednesday, March 02, 2005 6:34 AM
To: [email-masked]
Subject: [Megaco] processing order, errors, & wildcards

Hi all,

I'm having trouble reconciling these specs for ordered processing and for

In the first paragraph, "Commands within a Transaction are executed
sequentially" is very straightforward and would seem to apply regardless of
wildcards.

The second paragraph seems to reinforce that a command is executed on all
matching terminations moving to the next command.  But this only
*explicitly* refers to wildcarded terminations.

While this section is explicitly addressing wildcarded Contexts, it
specifies a behavior that is, IMO, against the letter and spirit of the
earlier quote from section 8.

Related questions:

In my first quote above from section 8, it says: "At the first failing
Command in a Transaction, ...".

What is a failing Command?
[KJBII] A command which cannot be executed in its entirety.

Does failing on a Descriptor for a Command mean you failed the Command?
[KJBII] Yes.

If so, I would conclude that other Descriptor's within the Command should

But this could be clearer.
[KJBII] I can try to add some editorial text making this clearer in the IGs
and V3.  I will include them for the July SG16 meeting.

Also...
In December we had a thread about whether the order of descriptors in a
response should match that of a request.  It seemed necessary to add this
requirement to distinguish what descriptor and error descriptor referred to.

But given the requirement to "restore state", it seems inappropriate to
return successful descriptors in the restored cases.  This leads to a
command request with multiple descriptors being answered by a command
response with (as little as) a single error descriptor and no way to know
which descriptor was the problem.
[KJBII] Descriptors are only returned if there is an update in their value.
So even in a successful command execution, you do not see the descriptors
for the most part.  As for failure, hopefully the responder will choose an
appropriate error code that will indicate where the error is.  For most
cases, there is a suitable error code that will identify the culprit
descriptor.

-troy