Subject: Re: Error Descriptor

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 11 Sep 2000 09:04:00 -0400

What John said in his latest note is that if you follow the chain:
 actionReply -> commandReply -> commandReplyList -> commandReplys
 -> (serviceChangeReply -> ... errorDescriptor
   / auditReply -> auditOther -> terminationAudit
   / ammsReply -> ... terminationAudit
   / notifyReply -> ... errorDescriptor )
and
  terminationAudit -> auditReturnParameter -> errorDescriptor

You have what you need on a per-command basis.

> -----Original Message-----
> From: Nurit Shenhar [mailto:[email-masked]]
> Sent: Monday, September 11, 2000 7:48 AM
> To: [email-masked]
> Subject: Re: Error Descriptor
>
>
> Hi John
>
> The ASN.1 permits having an error descriptor and the sequence of
> CommandReply. But still, if you have more than one command
> that failed, you
> can not have two error descriptors for each command, as the
> descriptor is
> per action.
>
> I don't like the idea of multiple ActionReplys. It will be
> difficult to
> match the request with the reply that way.
>
> Nurit
>
> -----Original Message-----
> From: John Segers [mailto:[email-masked]]
> Sent: Monday, September 11, 2000 12:22 PM
> To: [email-masked]
> Subject: Re: Error Descriptor
>
>
> Nurit,
>
> This indeed seems to be an error in the ABNF.  The ASN.1 structures do
> support the functionality described in the text you quoted from 8.2.2.
>
> I think that there are two options for resolving this issue.
>
> 1. Change the ABNF to match the structure of the ASN.1.
> 2. Create multiple action replies instead of one if both an error and
>    a command reply have to be returned.
>
> Any thoughts?
>
> John
>
> Nurit Shenhar wrote:
> >
> > Hi list
> >
> > The H.248 says the following: (
> >    ....
> >    command marked as Optional results in an error,
> subsequent commands
> >    in the Transaction will be executed.  A TransactionReply
> includes the
> >    results for all of the Commands in the corresponding
> >    TransactionRequest.  The TransactionReply includes the
> return values
> >    for the Commands that were executed successfully, and
> the Command and
> >    error descriptor for any Command that failed.
> TransactionPending is
> >       .....
> >
> > This means that each failed command should report an error.
> but the syntax
> > allows an error descriptor only on the action level,
> > and if the error descriptor appears, there can be not CommandReply:
> >
> >    actionReply          = CtxToken EQUAL ContextID LBRKT
> >                           ( errorDescriptor / commandReply ) RBRKT
> >
> >    commandReply       = (( contextProperties [COMMA
> commandReplyList] )
> >                            / commandReplyList )
> >
> >    commandReplyList     = commandReplys *(COMMA commandReplys )
> >
> >    commandReplys        = (serviceChangeReply / auditReply
> / ammsReply
> >                            / notifyReply )
> >
> > Shouldn't we have an error descriptor as one of the options in the
> > CommandReplys?
> >
> > Best regards
> >
> > Nurit Shenhar
> > AudioCodes Ltd.
> > Direct: +972-3-539-4155
> > Tel:     +972-3-539-4000
> > Fax:    +972-3-539-4040
> > email:  [email-masked]
> >
> > web:    <http://www.audiocodes.com>
>
> --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 303
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>