Subject: RE: [Megaco] Usage Of ContextId Wildcard

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Sep 2001 08:14:54 -0400

Okay, okay, guilty of not paying enough attention.

So you get Context=*{Termination=foo{Error=435....

Are we are in agreement?

Does anyone really think it is worth trying to change the
way the protocol works?  I don't, at this time.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, September 13, 2001 9:26 PM
> To: Mark Klerer
> Cc: Ian Leighton; Rosen, Brian; Russell-Laing, Andrew; [email-masked]
> Subject: Re: [Megaco] Usage Of ContextId Wildcard
> 
> 
> H.248 Annex L has some relevant information on this.
> 
> L.5.2.16 Error Code #: 435 Name: Termination ID is not in specified
> Context
> Definition: A specific TerminationID specified in a Modify, Subtract,
> AuditValue, AuditCapabilities, or ServiceChange command does not exist
> in a specified context and therefore the command is disregarded.
> Package: -
> Reference: -
> Error Text in error descriptor: The ContextID where the termination is
> located are included in the error text in the error descriptor.
> Comment: -
> 
> Therefore I think Context=ALL reply is correct. The NULL context is in
> the Error Descriptor text.
> 
> Regards, Christian
> 
> 
> Mark Klerer wrote:
> > 
> > Brian,
> > 
> > I believe Ian's response is correct. Since the ALL does not 
> include the NULL
> > context, the specific Termination is not in any of the 
> contexts sepecified.
> > 
> > Mark Klerer
> > 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Ian Leighton
> > Sent: Thursday, September 13, 2001 6:00 PM
> > To: Rosen, Brian
> > Cc: Russell-Laing, Andrew; [email-masked]
> > Subject: Re: [Megaco] Usage Of ContextId Wildcard
> > 
> > Comments below.
> > 
> > Regards
> > Ian
> > 
> > "Rosen, Brian" wrote:
> > 
> > > > In section 7.2.5 of RFC3015 it states that  ContextID  ALL
> > > > does not include the
> > > > null context.
> > > >
> > > > When using an AuditValue command with  ContextID = ALL and
> > > > TerminationID =
> > > > specific, we could have
> > > > the result that the specific termination is present in the
> > > > NULL context.
> > > >
> > > > Can anyone confirm that the correct MG response for this case
> > > > is to return a
> > > > transaction that specifies the NULL
> > > > contextID with an AuditValue reply containing an
> > > > errorDescriptor with ErrorCode
> > > > = 435 (TerminationID is not in
> > > > specified Context).
> > > My interpretation is that with the current definitions in the
> > > protocol, that this is correct.  I'm not too happy, but that is
> > > what it seems to me that you get.
> > 
> > We have implemented this differently. We will return ContextId = *,
> > TerminationId = specific, Error Descriptor 435. I would be 
> interested
> > in understanding which section of the protocol you are referring to.
> > 
> > It seems to me that if an MG was to send a reply with
> > ContextId=NULL,  TerminationId=specific, Error Descriptor
> > = 435, it would indicating the specified termination is not part
> > of the NULL context.
> > 
> > >
> > >
> > > >
> > > > It could be argued that this is not a true error situation
> > > > and that the
> > > > transaction response should specify the NULL
> > > > context with an an "empty" AuditValue reply.
> > > If there was to be any change, my preference would be to relax the
> > > 7.2.5 statement to have an exception in Audit, but I'm not
> > > really sure, at this time, I want to do that.
> > >
> > > Brian
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/megaco
> > 
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/megaco
> > 
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/megaco
> 

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

---

From: Ian Leighton <[email-masked]>
Date: Fri, 14 Sep 2001 19:03:20 -0400

Hi Brian/All

I agree.

What changes to the protocol are you referring to?

I was hoping to get something like the following added
to the IG (additions in blue, deletes in red). I hope that the
following would be considered clarifications and not protocol
changes.  I have only described changes to the AuditValue
command but I think that similar text is warranted in other
commands.

I hope to clarify the following issues

1) Are terminations in the NULL context processed when commands
with Context=* and term=* are requested.
2) The ContextId to use in replies when an error is encountered.
3) The ContextId's to use when multiple commands are present
in an Action with ContextID = *.
4) what error code is returned if ContextId = *, TermId = (* or
specific) and the contextId's don't match.

7.2.5 AuditValue

...

TerminationID may be specific or wildcarded. The ALL wildcard
applies to the terminations that are available in the Context
or Contexts specified in the Action. If the wildcard matches
more than one TerminationID, all possible matches are attempted,
with results reported for each one.  The order of attempts when
multiple  TerminationIDs match is not specified. If the ALL
TerminationId is specified and no matches are found an error
descriptor 435 "Termination is not in specified Context" is
sent in the reply. If the TerminationId is specific and it does
not match any of the TerminationIds then the error descriptor
435 "Termination is not in specified Context" is sent in the
reply. If a wildcarded response is requested, only one command
return is generated, with the contents containing the union of
the values of all Terminations matching the wildcard. This
convention may reduce the volume of data required to audit a
group of Terminations.  Use of CHOOSE is an error.

...

8.2.1 TransactionRequest

The TransactionRequest is invoked by the sender.  There is one
Transaction per request invocation.  A request contains one or more
Actions, each of which specifies one or more its target Context(s)
and one or more Commands per Context.

      TransactionRequest(TransactionId {
             ContextID {Command _ Command},
                              . . .
             ContextID  {Command _ Command } })

The TransactionID parameter must specify a value for later
correlation with the TransactionReply or TransactionPending response
from the receiver.

The ContextID parameter must specify a value to pertain to all
Commands that follow up to either the next specification of a
ContextID parameter or the end of the TransactionRequest, whichever
comes first. If the ContextId is a wildcard id (ie. ALL and CHOOSE),
then the ContextIDs are determined with respect to the first command
in the Action. All subsequent commands up to the end of the Action
are invoked with the ContextId or ContextId's resulting from the
first Command.

...

8.2.2 TransactionReply

...

Each of the Response parameters represents a return value as
mentioned in section 7.2, or an error descriptor if the command
execution encountered an error. If an error is encountered
while processing a Command with a specific or CHOOSE
TerminationId the input ContextId is returned in the Response.
If one or more errors are encountered while processing a Command
with an ALL TerminationId, then the errored Commands use the
input ContextId to encode the Response ContextID. Commands
after the point of failure are not processed and, therefore,
Responses are not issued for them.

...

Comment/Correction/Clarifications are encouraged.

Regards
Ian Leighton