Subject: RE: [Megaco] Transaction responses & error codes

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 18 Jan 2005 17:21:11 -0500

When I refer to message construction, I refer to the levels of the message
as to where the elements appear.  This means that commands appear at the
command level and (most) descriptors appear at the descriptor level. Let's
take an example message:

!/1 [12.34.56.78]:2944
T=123{C=12{MF=term1{SG{cg/dt},E=123{al/of{strict=state}}},A=${etc...}},C=13{
etc...}} T=124{etc...}

Let's format this into various levels:

!/1 [12.34.56.78:2944              ;Message level
   T=123                           ;Trans level
   {
      C=12                         ;Action level
      {
         MF=term1                  ;Command level
         {
            SG                     ;Descriptor level
            {
               cg/dt               ;"Property" level
            },
            E=123                  ;Descriptor level
            {
               al/of               ;"Property" level
               {
                  strict=state     ;Parameter level
               }
            }
         },
         A=$                       ;Command level
         {
            etc...
         }
      },
      C=13                         ;Action level
      {
         etc...
      }
   }
   T=124                           ;Transaction level
   {
      etc...
   }

("Property" here is the generic definition of property, not the package item
definition of property)

This leads to a uniform description of the levels, whether we are talking
about error descriptors or not.  

Further comments inline. [KJBII]

Kevin 

-----Original Message-----
From: Jon Rowland [mailto:[email-masked]] 
Sent: Tuesday, January 18, 2005 12:05 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] Transaction responses & error codes

Hi Kevin,

Had some thoughts on your mail below - some semantic, some technical.

Comments below marked [JTR].

Cheers,
Jon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 18 January 2005 15:54
To: [email-masked]; [email-masked]
Subject: RE: [Megaco] Transaction responses & error codes

This would all depend on when the MG knows there is an error.
[JTR] Agreed.

First let me point out that your two sample responses are placing the error
descriptor at the command and descriptor levels, respectively, and not the
action and command levels as asserted.  It is important to have a common
frame of reference to avoid confusion when talking about message
construction.

[JTR] I don't think I agree. I think the error levels Aliza specified are
correct. The two levels you specify below, I would categorise as being at
the action-level and the transaction-level. I think it makes sense to
categorise errors as being at the level of the thing the error refers to, so
I would consider your definitions to be 'one too low' by referring to the
syntactic point in the message the error descriptor sits, rather than the
part of the message that is in error.

To clarify my understanding, I think the level of the error descriptor is
the syntax element it appears _within_:
Message-level error:
!/2 [10.0.0.1]
ER=1

Transaction-level error:
!/2 [10.0.0.1]
P=206{ER=1}

Action-level error:
!/2 [10.0.0.1]
P=206{C=*{ER=1}}

Command-level error:
!/2 [10.0.0.1]
P=206{C=123{MF=line/1{ER=1}}}

[JTR] I realise this is just semantics, but this definition feels
intuitively like the most helpful one! I'm happy to hear counter-suggestions
:-)

[KJBII] See above.

Taking your example, lets assume that the MG has contexts, but line/1 is in
NULL (as you state).  The MG cannot know there is an error at the action
level; it has to wait until the command level to figure out the mistake.
However, once at the command level, the MG will know right away upon parsing
the termID that there is a problem.  The MG can stop right there, and place
an error descriptor at the command level:

P=206{C=*{ER=435{"Termination ID is not in specified context"}}} (Note that
the error code you used in your example is incorrect -- it only applies to
wildcarded termIDs.)

[JTR] Don't agree about error code. See 6.3.2/H.248.1 (01/2004). Error 431
is to be used for exactly this situation. See also my previous email to the
list 'On wildcarding and 435 error code' from last week.

[KJBII] This actually conflicts with the definition in H.248.8.  H.248.8
defines 435 to mean that a wildcarded TerminationID doesn't have any match.
We will have to resolve this at the next meeting.

[JTR] However, if you _were_ to respond with a 435 error, then I think it
makes sense to do so at the command-level (my definition!), so the response
includes the termination ID that is at fault!

[KJBII] Why can't the termID be placed in the error descriptor text?  The
response would include the termID and place the error descriptor at the
logical level for the error.

What if the MG had NO contexts?  In this instance, the MG knows without even
getting to the command level that there is a problem.  Halt and add the
error descriptor at the action level:

P=206{ER=411{"The transaction refers to an unknown contextID"}}

[JTR] I think this error is fine, but would also be acceptable at the
action-level (given my above definitions), and would be more helpful there,
as it includes the context ID that is at fault. In general including the
error descriptor at the deepest level in the message that is applicable to
the error (and can be parsed by the MG) provides more information on the
response.

[KJBII] Again, you can place the at-fault info in the error descriptor if
you so choose.  I would note that the error occurred when parsing the
contextID, so instead of placing a bad contextID in the response with the
Context token, it may be better to segregate the bad info into the error
text.

Place the error descriptor at the descriptor level (as in your second sample
reply) if the error cannot be detected until processing individual
descriptors.  This would occur if the MGC included a package item (signal,
event, etc.) that the MG does not support, for example:

P=512{C=123{MF=line/3{ER=440{"Unsupported or unknown package"}}}}

So, place the error at the level it can be determined that there is a
problem.

[JTR] I agree with this general philosophy. To answer Aliza's initial
question, I think either of the suggested responses below is acceptable and
any MGC implementation should be able to cope with either.

[KJBII] Given that H.248 specifies that parsing may halt at the point where
an error is detected, there is no need to place an error descriptor further
down in the message than that.  Assuming that the reply is being built as
the message is being parsed, the responder would generally not want to waste
time building a piece of a response until it has verified to the best of its
ability that the information for that level parses.  Once it has verified
it, then add the new piece to the response buffer.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, January 18, 2005 5:17 AM
To: [email-masked]
Subject: [Megaco] Transaction responses & error codes

Hello,

I have a question regarding transaction responses that includes error.

Error descriptor can be set in the Transaction level (transactionReply), in
the Action Level (actionReply), and in the Command level (specific command
reply).

Can you please clarify the rules to set each of the error descriptors. When
the error descriptor should be set in the transaction level, and when in
Action Level etc.

Consider the following example:

Transaction=206{

Context=*{AuditValue=line/1{Audit{media,packages,observedevents}}}}

If line/1 is not in any non-null context the error code 431 should be
reported as action error descriptor, or command error descriptor:

Reply=206{
      Context=*{
            Error=431{"No TerminationID matched a wildcard"}
      }
}

or

Reply=206{
    Context=*{
        AuditValue=line/2{Error=431{"No TerminationID matched a wildcard"}
      }
    }
}

Thanks, Aliza

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

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

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

---

From: "Pascal Lambers" <[email-masked]>
Date: Wed, 19 Jan 2005 00:05:24 +0100

I see the error levels as Kevin sees them, but mapping the list of error levels provided by Jon to the levels as seen by Kevin, what is message level error then? It appears to be missing (see <???????> below), and even a Transaction-level error makes little sense, as the (eg MGC) application receiving this error reply message does no longer know which TransactionId this reply matches to. So;

  Message-level error
  <???>

  Transaction-level error:
  !/2 [10.0.0.1]
  ER=1

  Action-level error:
  !/2 [10.0.0.1]
  P=206{ER=1}

  Command-level error:
  !/2 [10.0.0.1]
  P=206{C=*{ER=1}}

  Descriptor-level error:
  !/2 [10.0.0.1]

Pascal