Subject: RE: [Megaco] questions about syntax error

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 8 Mar 2002 13:18:04 -0500

Hi.  I've reconsidered my previous answer, based on an analysis of the
possible forms of request and response to an action.  I wouldn't be
surprised if people disagree with my conclusions.

I think the intent of what we have specified on context life and death is
captured by the following principle: any actionRequest which identifies a
non-existent context MUST contain at least one command, and the first
command MUST be an Add.  If this condition is not satisfied, the response to
the actionRequest is an actionReply of the form
   CtxToken EQUAL ContextID LBRKT errorDescriptor RBRKT
where the error is 
   "411 - The transaction refers to an unknown ContextId".

Here are the possible cases:
  i) actionRequest = CtxToken EQUAL ContextID LBRKT 
                        contextRequest RBRKT
     Response as above.

 ii) actionRequest = CtxToken EQUAL ContextID LBRKT
                        commandRequest ... RBRKT
     If the first command is not an Add, response as above.
     Otherwise processing and error responses continue at the command 
     and descriptor level.

iii) actionRequest = CtxToken EQUAL ContextID LBRKT contextRequest 
                        COMMA commandRequest ... RBRKT
     Same treatment as previous case, except that the response when 
     the first command was an Add may include context properties in 
     response to a context audit.
 
 iv) actionRequest = CtxToken EQUAL ContextID LBRKT 
                        "O-" commandRequest ... RBRKT
     Processing continues up to the earliest of:
           -- Add command encountered
           -- non-optional command encountered
           -- end of action.
     All optional commands up to that point are replied with an error
     descriptor, error 411.  The exact syntax for each is:
           "O-" <command token> EQUAL TerminationID LBRKT 
                        errorDescriptor RBRKT
     Where processing is ended by a non-
     optional command which is not an Add, one more copy of the error
     descriptor is added for that command and the response is returned.
     Where processing is ended by the end of the action, the response
     containing one error descriptor for each optional command is
     returned.  Finally, if an Add command is encountered, processing
     and error responses continue at the command and descriptor level.

-----Original Message-----
From: Cristina Sanchez [mailto:[email-masked]]
Sent: Friday, March 08, 2002 8:36 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]
Subject: Re: [Megaco] questions about syntax error

Thanks for the clarifications.
See some questions below.

Tom-PT Taylor wrote:

> As I understand the logic we have defined, processing will proceed as
> follows:
>
>   1) It is not forbidden for the MGC to give an explicit identifier for a
> new context, so "context=34{" will be provisionally accepted.  A new
context
> will be created with that identifier.

Then, MG never uses the error code
"411 - The transaction refers to an unknown ContextId"
am I wrong ?

>
>   2) Because the first command is optional, it generates an error but does
> not halt the transaction.

Error code would be  : 431 - No TerminationID matched a wildcard
Is it right?

>
>   3) Reaching the end of the first action, the MG determines that the new
> context contains no terminations and deletes it.
>
>   4) Assuming A5555 is in the Null context, the second action is processed
> successfully.
>
> -----Original Message-----
> From: Cristina Sanchez [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 5:34 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Megaco] questions about syntax error
>
> Hi.
> A related question with an example taken from a real application.
> Consider that Context 34 does not exist in an MG  and it receives the
> following
> ...
>    Transaction=1 {
>        Context= 34 {O-Substract = *},   ; Optional command
>        Context= - {Modify=A5555{...}}
>    }
> Shall the second command be processed by the MG ?
> What would be the Reply message ?
>
> Regards,
> Cristina
>
> Tom-PT Taylor wrote:
>
> > Hi.  Answers below.
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, March 04, 2002 4:55 AM
> > To: [email-masked]
> > Subject: [Megaco] questions about syntax error
> >
> > hi, list.
> > consider the example message below.
> > MEGACO/1 [125.125.125.111]:55555
> > Transaction = 10000 {
> >     Context - 5000 {
> >         // syntax error in Action
> >         Subtract= A4444 {
> >              ...
> >         }
> >     },
> >     Context = 4900 {
> >         Add=A5555 {
> >             ...
> >          }
> >          Add=A7777 {
> >            ...
> >          }
> >     }
> > }
> > In real application, I think this example maybe hardly happens. but
> anyway,
> > in above case, shall the second action be processed by MG? or shall MG
> just
> > send TransactionReply
> > with a error descriptor about the first action and do not precess the
> > second action?
> >
> > [PTT] The first error encounters stops the processing of the
transaction.
> > You get the error descriptor for the first action and that is all.  See
> > section 8.2.2.
> >
> > if error descriptor and action reply be sent at the same transaction
> reply,
> > then ABNF grammer does not allow this.
> > ABNF grammer reads
> > "
> > transactionReply=ReplyToken EQUAL TransactionID LBRKT
> >                          [ImmAckRequiredToken COMMA]
> >                          (errorDescriptor/actionReplyList) RBRKT
> > "
> > and the second example message below
> > (it is originally come from Sundareswaram P V)
> > case 1)
> > MEGACO/1 [125.125.125.111]:55555
> > Transaction = 50009 {
> >    Context = 5000 {
> >       Subtract = A5555 {
> >          Statistics {
> >             ........
> >          }
> >        },
> >        abc = A5556 {
> >                     // --- 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
> >                }
> >            }
> >         }
> >  }
> >
> > [PTT] We modified the ABNF to accommodate this case.  actionReply is now
> > defined as
> >
> > actionReply  = CtxToken EQUAL ContextID LBRKT
> >                ( errorDescriptor / commandReply /
> >                    (commandReply COMMA errorDescriptor) ) RBRKT
> >
> > case 2)
> > MEGACO/1 [125.125.125.111]:55555
> > Transaction = 50009 {
> >    Context = 5000 {
> >        abc = A5556 {
> >                     // --- 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
> >                }
> >            }
> >         },
> >       Subtract = A5555 {
> >          Statistics {
> >             ........
> >          }
> >        }
> >  }
> > In case 1, Can I think in following manner?
> >         1) it is neeed to send both error descriptor and command reply,
> and
> >         2) ABNF grammer will address this problem
> > In case 2, as long as a parser can not determine the first command is
> > "optional", must not  the second command be processed by MG? and will a
> > error descriptor for the first command be placed in actionReply?
> > thanks in advance.
> >
> > [PTT] In the text encoding, an optional command is indicated by a
> preceding
> > "O-" tag.  If this tag is present AND the end of the faulty command can
be
> > detected, then an error descriptor for the optional command plus a
further
> > response for following commands should be sent.
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
>

Regards,
--
Cristina Sanchez Moreno
Alcatel VND Wireline Systems
mailto:[email-masked]

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

---

From: Cristina Sanchez <[email-masked]>
Date: Tue, 12 Mar 2002 12:40:17 +0100

Hi. Thanks again for the time you spent on clarifying the issue.

If I understood well,  for the concrete example of the MG receiving :
   Transaction=1 {
      Context= 34 {O-Substract = *},   ; Optional command
      Context= - {Modify=A5555{...}}
    }
in case Context 34 does not exist in the MG, the answer should be :
 Reply=1 {
      Context= 34 { "411 - The transaction refers to an unknown ContextId"},
      Context= - {Modify=...}
   }

I find this result is quite in line with what one would expect intuitively.
A question : will your clarification be added to the standard ?
Regards,
Cristina

---

From: Cristina Sanchez <[email-masked]>
Date: Tue, 12 Mar 2002 12:40:17 +0100