Subject: [Megaco] Transaction responses & error codes

From: [email-masked]
Date: Tue, 18 Jan 2005 12:17:18 +0200

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 18 Jan 2005 10:54:12 -0500

This would all depend on when the MG knows there is an error.

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.

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

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

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.

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,

Transaction=206{

Reply=206{
      Context=*{

or

Reply=206{
    Context=*{

Thanks, Aliza

---

From: "Jon Rowland" <[email-masked]>
Date: Tue, 18 Jan 2005 17:05:04 -0000

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

[JTR] Agreed.

[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 :-)

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

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

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

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

Kevin

-----Original Message-----

Hello,

Transaction=206{

Reply=206{
      Context=*{

or

Reply=206{
    Context=*{

Thanks, Aliza