Subject: RE: [Megaco] Transaction Reply - Error Handling

From: "David Stonehouse" <[email-masked]>
Date: Fri, 5 Oct 2001 12:50:06 -0400

I agree that IG section 8.2.2 needs to be addressed to make things clear.
Here are my thoughts on this, and proposals on how to address it:
1. It should be allowable to tack on an error descriptor (including a syntax
error) anywhere in a reply.  
2. The grammar currently makes this tricky because of the construction rules
that force an "either error descriptor or reply list" at the top of the
transaction or action.  
3. My preference would be to change the grammar (see point 5).  A workaround
for the situation expressed in Implementor's Guide section 8.2.2 is to
create a "dummy" context and add the error descriptor inside of it.
4. The Dummy context needs a context ID. A previous post on this topic
suggested "NULL", which seems reasonable. See message entitled:

[Megaco] [Megaco]: Syntax error at the end of a transaction ("missing  }")

5. I would prefer not to do this ugly workaround and instead change the
grammar to allow for error descriptors to occur anywhere in a message.  Here
are the proposed changes:

   messageBody          = transactionList

   transactionList      = 1*( errorDescriptor / 
                       transactionRequest / transactionReply / 
                       transactionPending / transactionResponseAck )

   transactionReply     = ReplyToken EQUAL TransactionID LBRKT
                           [ ImmAckRequiredToken COMMA]
                          actionReplyList RBRKT
   actionReplyList      = actionReply *(COMMA actionReply )

   actionReply          = ( (CtxToken EQUAL ContextID LBRKT
                          commandReply RBRKT) 
				  / errorDescriptor )

   commandReply       = (( contextProperties [COMMA commandReplyList] )
                           / commandReplyList )

   commandReplyList     = commandReplys *(COMMA commandReplys )

   commandReplys        = ( serviceChangeReply / auditReply / ammsReply
                           / notifyReply / errorDescriptor )

Dave

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2001 6:49 AM
> To: [email-masked]
> Subject: [Megaco] Transaction Reply - Error Handling
> 
> 
> Hi  List
> 
> In the H.248 Implementors guide section 6.84 a correction to 
> section 8.2.2
> of protocol has introduced an ambiguity.
> 
> In the text :-
> 
> "If the end of an action cannot be reliably determined but one or more
> (strikethrough: actions ) commands can be parsed, it will 
> process them and
> send 422 syntax error in action as the last action for the 
> transaction."
> 
> 
> It was previously clear that :-
> 
> - for a transaction with 2 actions then the commands in the 
> first action
> would be processed and the commands in the second action would not be
> processed. The second action reply would contain an error descriptor
> instead.
> 
> - for a transaction with 1 action then the commands would not 
> be processed
> and the action reply would contain an error descriptor.
> 
> As an action reply can contain a list of command replies OR an
> errordescriptor, then the corrected statement is wrong to
> imply that commands will be processed in a single action transaction,
> because it would not be possible to include
> the command replies in that action reply.
> 
> Can someone pleasy clarify the intention of this implementors guide
> correction.
> 
> Thanks.
> 
> Andrew Russell-Laing
> Marconi
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/megaco
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 08 Oct 2001 16:49:18 +1000

Hello David, 

I haven't checked the ABNF but the ASN1 version allows you to return
errordescriptors anywhere in the reply. ie. you can send an error
descriptor and several commands so IG 6.84 is correct for the binary
version. So you can return the succesfully completed commands and an
error descriptor for the error in the action. I believe the intention
was always to be able to return the error descriptor in various places
in the message.

ie.
ActionReply ::= SEQUENCE
{
	contextId 		ContextID,
	errorDescriptor	ErrorDescriptor OPTIONAL,
	contextReply	ContextRequest OPTIONAL,
	commandReply 	SEQUENCE OF CommandReply
}

Cheers, Christian

David Stonehouse wrote:
> 
> I agree that IG section 8.2.2 needs to be addressed to make things
> clear. Here are my thoughts on this, and proposals on how to address
> it:
> 
> 1. It should be allowable to tack on an error descriptor (including a
> syntax error) anywhere in a reply.
> 2. The grammar currently makes this tricky because of the construction
> rules that force an "either error descriptor or reply list" at the top
> of the transaction or action.
> 
> 3. My preference would be to change the grammar (see point 5).  A
> workaround for the situation expressed in Implementor's Guide section
> 8.2.2 is to create a "dummy" context and add the error descriptor
> inside of it.
> 
> 5. I would prefer not to do this ugly workaround and instead change
> the grammar to allow for error descriptors to occur anywhere in a
> message.  Here are the proposed changes:
>

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 31 Oct 2001 19:10:35 -0500

I believe that the correct reply for both binary and text are similar and
allowed by the syntax.  If one or more commands in an action succeed and
then one fails one should return the normal replies for those that succeeded
along with an errorDescriptor for the one that failed.  The location of the
error descriptor may be a little obscure to human readers but in both cases
is in auditReply (or AuditReply).  This allows the command that failed to
still be indicated along with the terminationId followed by the
errorDescriptor.

for ASN.1
ActionReply:: SEQUENCE
{
    contextId    ContextID,
    commandReply  SEQUENCE
    {
        addReply / moveReply / modReply / subtractReply    ammsReply
SEQUENCE
            {
                terminationID    TerminationIDList,
                terminationAudit   TerminationAudit  OPTIONAL SEQUENCE OF
                    {
                        -- various descriptors for those that succeed
                        errorDescriptor ErrorDescriptor  -- for the one that
fails
                    }
            }
     }

}

Similarly for the text actionReply can be
Context = <contextId> {
    Add <termId>,
    Subtract <termId> {<some descriptors>},     ; etc for those that succeed

    Modify <termId> {<errorDescriptor>}    ; for the one that fails
}

since
    ammsReply = (AddToken / MoveToken / ModifyToken /
                        SubtractToken ) EQUAL TerminationID [ LBRKT
                        terminationAudit RBRKT ]

and
    terminationAudit   = auditReturnParameter *(COMMA auditReturnParameter)

    auditReturnParameter = (mediaDescriptor / modemDescriptor /
                        muxDescriptor / eventsDescriptor /
                        signalsDescriptor / digitMapDescriptor /
                        observedEventsDescriptor /
                        eventBufferDescriptor /
                        statisticsDescriptor / packagesDescriptor /
                        errorDescriptor / auditItem)

which includes the errorDescriptor which is needed.

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 31 Oct 2001 19:10:35 -0500

for ASN.1
ActionReply:: SEQUENCE
{
    contextId    ContextID,
    commandReply  SEQUENCE
    {

}

since

and

--