Subject: RE: [Megaco] Re: Open Issue #4: Doubt regarding sending Error in Transaction Reply.

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 23 Jan 2002 13:10:13 -0500

I half-prepared a reply on this issue back when it was first raised, but
didn't get around to finishing it.  The real issue is what to do when there
has been an unrecognizable command.  If you follow through the ABNF all
other cases are covered, because auditReturnParameter includes
errorDescriptor as one of its alternatives.

I'd suggest an ABNF correction of the form:

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

with a comment that multiple errorDescriptors would be allowed only if all
except the last pertained to commands that had the "O-" (optional) prefix.

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Wednesday, January 23, 2002 11:37 AM
To: Megaco Mailing List
Subject: [Megaco] Re: Open Issue #4: Doubt regarding sending Error in
Transaction Reply.

I'm copying the list (and designating it as open issue #4) since it has
become
an IG issue.  See below.

Christian Groves wrote:

> G'Day Terry and Sundar,
>
> The binary coding allows you to send an ErrorDescriptor and a sequence
> of commandReplies.
>
> ActionReply ::= SEQUENCE
> {
>         contextId               ContextID,
>         errorDescriptor ErrorDescriptor OPTIONAL,
>         contextReply    ContextRequest OPTIONAL,
>         commandReply    SEQUENCE OF CommandReply
> }

Oh, I hadn't noticed the difference.  The sequence is also allowed in the
ABNF
since commandReply there is a comma separated list, but it does NOT allow
both
commandReply AND errorDescriptor as the ASN.1 does.

Do you think we should "correct" the ABNF to agree with ASN.1.  We've often
done this and it would solve the problem of no way to return replies for the
successes along with the error.

The change making it most like the ASN.1 would be:
actionReply    = CtxToken EQUAL ContextID LBRKT
                        ( errorDescriptor / commandReply /
                            commandReply COMMA errorDescriptor ) RBRKT

The ASN.1 encodes the errorDescriptor first, but the description in 8.2.2
would be clearer if errorDescriptor came after commandReply (which is a
list),
so I am suggesting the order above for ABNF where the error looks more like
part of the reply sequence.

> So in the case Sundar talks about you would send an error for "Syntax
> error in action" and also return the commandReply for the command that
> the MG processed.
>
> With regards to 6.84, "last action REPLY" does make things clearer but I
> don't think other changes are needed.

you don't think the other changes IN 6.84 are needed or other changes TO
6.84???

> Regards, Christian
>
> Terry L Anderson wrote:
> >
> > ErrorDescriptor is available at several levels in a reply including
> > action and most command. Discussion of where the errorDescriptor should
> > appear in the reply is in 7.1.19, 8.0 and 8.2.2.
> >
> > 8.2.2 says that if MG cannot determine a legal action it returns 422 as
> > the actionReply.  I guess I would argue that this is NOT a legal action,
> > since it contains an unknown command.
> >
> > The next sentence deals with a special case where the end of an action
> > cannot be determined, but this is not really the case here.  IG 6.84
> > modified this sentence to refer to the case where one or more COMMANDS
> > in the action can be parsed, and so it might be tempting to follow this
> > case, but on reading it, I think the change is wrong.
> >
> > Christian, IG 6.84 was approved in Porto Seguro, one of the last before
> > you turned it over to me, and was suggested by Paul Long, but I do not
> > see how it works.  The rest of the sentence still refers to Action ("422
> > syntax Error in ACTION as the last ACTION for the transaction" - I
> > believe it should be "last action REPLY for").  I believe that it WAS
> > intended to say "Action" as it did before 6.84, and only means that if
> > other PRECEDING Actions in the transaction before the one with
> > failed-end-parse should be processed but the entire failed Action must
> > result in an actionReply of ErrorDescriptor.  As modified the processed
> > Commands cannot return replies because of the action reply containing
> > the error.
> >
> > There are two cases if a command cannot be parsed.  (1) If the command
> > type can be determined but there is a parse failure inside (eg, Add,
> > Move, Modify, Subtract), then we have the valid command token and can
> > use the errorDescriptor (in terminationAudit) in ammsReply and similarly
> > for audit, notify, and serviceChangeRequest.
> >
> > (2) parse (as above) fails without a valid command type.  Here we have
> > no command token to use in any of the *Reply and there is no
> > errorDescriptor in commandReplys, so one is forced to use the one in
> > actionReply and fail the entire action.  It would have been nice to have
> > errorDescriptor in commandReplys to take care of this case.
> >
> > Except for this last case one could fix the IG6.84 item by changing the
> > other instance of "Action" to command as well ('in the last command
> > reply'), but perhaps this should be stated for both the action and
> > command level.
> >
> > Sundareswaram P V wrote:
> >
> > > Hi,     cud u help in having a solution for the same. The following is
> > > the Query.  consider the example message below. MEGACO/1
> > > [125.125.125.111]:55555
> > > Transaction = 50009 {
> > >    Context = 5000 {
> > >       Subtract = A5555 {
> > >          Statistics {
> > >             ........
> > >          }
> > >        },
> > >        abc = A5556 {                    // --- Command request type is
> > > Corrupted                    // instead of subtract it become 'abc'
> > >                Statistics {
> > >                   ......
> > >                     nt/os=62345, ; octets sent
> > >                     rtp/pr=780, ; packets received
> > >                     nt/or=45123, ; octets received
> > >                }
> > >            }
> > >         }
> > >      }     The problem is as follows :         In the same context we
> > > have two commands. the first command get parsed well and will be
> > > inserted in to the Action Request while in the second command, the
> > > command type it self is corrupted. so how, do i form the ActionReply
> > > :         as the RFC 3015 states :             action reply = CtxToken
> > > EQUAL ContextID LBRKT                          (ErrorDescriptor /
> > > Command Reply) RBRKT             but as such for an action request i
> > > can send only one action reply. but the syntax above doesn't allow me
> > > to set both an error descriptor and an command reply with in an action
> > > reply.             cud any one help me resolve the issue  ??  thanx in
> > > advance. rgds,Sundar.
> >
> > --
> >
> > ------------------------------------------------------------
> > 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

--

------------------------------------------------------------
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

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

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 23 Jan 2002 14:34:26 -0500

I think my change is more focused.  We do not need multiple commandReply
instances since it is already a comma separated list.  If we support multiple
errorDescriptor instances we would need to change ASN.1 too, since it does NOT.

Also your change would need a separator (eg. COMMA) between instances.  If we
really want multiple instances of each it would be easier to add errorDescriptor
to commandReplys so they could appear in the commandReplyList which already has
the separator.  But again this would introduce a new difference from ASN.1

I think simply matching the ASN.1 (as I tried to do) takes care of the one need.

--

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 23 Jan 2002 14:34:26 -0500

--