Subject: Re: Error Descriptor

From: Nurit Shenhar <[email-masked]>
Date: Mon, 11 Sep 2000 13:48:27 +0200

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

---

From: John Segers <[email-masked]>
Date: Mon, 11 Sep 2000 13:16:09 +0200

Nurit,

Your statement is correct: the case where execution of an optional (o-)
command generates multiple errors is not covered.  I never thought of
this one.

I agree that using multiple action replies is not very nice.  The reason
I mentioned it as an option is that it is a solution that doesn't
require a syntactic change.  The other solution, semantically better,
does require syntax changes.

Cheers,

John

---

From: John Segers <[email-masked]>
Date: Mon, 11 Sep 2000 13:42:51 +0200

Nurit,

I checked the protocol document after I sent my previous reply and
learnt that my memory is is not as good as I'd like it to be:
serviceChangeReply, auditReply, ammsReply, and notifyReply can all
contain error descriptors.  notifyReply and serviceChangeReply contain
error descriptors directly:

notifyReply          = NotifyToken EQUAL TerminationID
                       [ LBRKT errorDescriptor RBRKT ]
...
serviceChangeReply   = ServiceChangeToken EQUAL TerminationID
                       [LBRKT (errorDescriptor /
                       serviceChangeReplyDescriptor) RBRKT]

ammsReply and auditReply refer to terminationAudit, and that contains
errorDescriptor.

Sorry about the wasted bandwidth!

Cheers,

John