Subject: RE: [MEGACO] Questions about Annex L

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 12 Feb 2001 19:22:48 -0500

I thought someone else would jump in, but I guess I'm nominated.

> -----Original Message-----
> From: Griffeth, Nancy D (Nancy) [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2001 1:56 PM
> To: [email-masked]
> Subject: [MEGACO] Questions about Annex L
> 
> 
> Folks,
> 
> I'm trying to come up with test cases that will generate the 
> errors in Annex
> L, but I'm not always sure
> what the errors are.  Here are my questions:
> 
> In general:
> 
> When the error description says a command is "disregarded", 
> does that mean
> to go
> on processing subsequent commands even if the command was not 
> optional?
[PTT]
That is not the intent.  We should change the phrasing to say "normal action
for a failed command is taken, as specified in section 8".

> 
> Error 401, "Protocol error": Does this happen when a 
> transaction is out of
> order or inappropriate, like
> a TransactionReply without a corresponding 
> TransactionRequest?  Could it
> mean an inappropriate command,
> like subtracting a termination from a context that it's not in?

[PTT]
I like your first example but not the second one.  I think "Protocol Error"
covers material that is syntactically correct but unexpected in the current
situation.  That could include things like unexpected descriptors in
commands, commands sent in the wrong direction, or your example of a reply
without a corresponding request.  There could also be violations of expected
timing behaviour, but these are likely to masquertade as other types of
errors.
 
> 
> Error 402, "unauthorized":
> This doesn't mean what I think it should mean, but that may 
> be my problem.
> Here's my (probably faulty) reasoning:
> 1) The description in Annex L says the originator of the 
> message is not
> authorized to perform the command on a
> termination.
> 2) The position of this error in the list suggests it should 
> apply to the
> whole message, not to one command.
> 3) There's another error code, 504, that's not used but addresses
> unauthorized originators of commands on a termination.
> 4) There isn't an error code for an incorrect authorization 
> header, which
> also seems necessary.
> Perhaps 402 should mean an incorrect authorization header, 
> and use 504 for
> originator not authorized for command?

[PTT] I think you have a good point, even though the Interim AH won't be
seen very much in the field.  I can think of three or four situations where
authorization gets involved:
 -- MG tries to hook up with the wrong MGC -- likely to be rejected at a
lower level (i.e. IPSEC) but it's possible this could happen at the
application level
 -- an MGC tries to do something to ROOT where it controls a virtual MG but
not ROOT
 -- an MGC tries to change the service state of a termination, but the MG is
configured not to allow it to do so

I suppose we can summarize by saying there are situations where the other
party shouldn't even be trying to talk to this one, hence a 402 might be
applicable, and other situations where it's a matter of the individual
termination and perhaps use 504 instead.  I'm not sure we really need to
distinguish the two, but other people can comment.
> 
> In error 443, what's the "commandID" that's supposed to be 
> included in the
> error text?  Would it be the
> command token (e.g., "Edit" or "ED" doesn't correspond to any 
> command)?

[PTT]
Yes.

> Could this error occur in the
> BER encoding?  Given the way the commands are defined in 
> ASN.1, it seems
> like the encoding step would
> prevent it from happening.  But if it did, what would be the 
> commandID?  The
> BER-encoded id would not seem
> to be useful in an error message.

[PTT]
I would think the command value would have some debugging usefulness,
particularly if the entire message is appended as dadditional debugging
data.  It would give some additional indication of where the parser
glitched.
> 
> In error 446, what does "parameter" mean?  I see two possible 
> sources of
> parameters: one is the
> descriptors, described in the ABNF syntax as "ammParameter" 
> and the other is
> parameters of events and
> signals in the packages.  If it means the former, how does 
> this differ from
> error 444?  If the latter, why isn't
> it in sequence with 450-455?

[PTT]
If you flip through section 6 of RFC3015/H.248 you'll find the word
"parameter" used in a variety of ways.  Error 446 applies generally, not
just to packaged items.
> 
> Error 453: The statisticsDescriptor is never sent to the MG; 
> the MG sends it
> to the MGC.  So, wouldn't this
> error appear only in the MGC->MG direction.

[PTT]
Your first statement is correct; the second isn't, but I suspect you
mis-typed.  At the moment, this error would never be reported because it
would be found by the MGC in a transaction response, and no errors are sent
back in that case.
> 
> Error 454: Seems to be a missing "not"

[PTT]
True.  Needs a bit of cleaning up.
> 
> Error 455: Should it refer to a "property" rather than a 
> "parameter"?   Or
> "propertyParm"?
> 
> Error 456: What is a parameter in a descriptor?  I'm still 
> confused about
> how the term "parameter" is being used.

[PTT]
After I replied above, I came across section 7.1.1 as another example of our
varied use of the term "parameter".

Thanks for your comments.
> Nancy Griffeth