Subject: RE: [Megaco] Usage Of ContextId Wildcard

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 17 Sep 2001 13:55:02 -0400

The protocol change was one changing ALL to include NULL for
audit.
 
I don't see that we need such extensive wording changes in the
text. I think editing the Annex L text to include this specific case,
and noting that the reply of a command with a wildcarded
ContextId may be the original wildcarded ContextId when the
error is not limited to a specific matching value should be enough.
 
Brian 

-----Original Message-----
From: Ian Leighton [mailto:[email-masked]]
Sent: Friday, September 14, 2001 7:03 PM
To: Rosen, Brian; [email-masked]
Cc: 'Christian Groves'; Mark Klerer; Russell-Laing, Andrew
Subject: Re: [Megaco] Usage Of ContextId Wildcard

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 

"Rosen, Brian" wrote: 

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]
<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] <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
<http://www1.ietf.org/mailman/listinfo/megaco>  
> > 
> > _______________________________________________ 
> > Megaco mailing list 
> > [email-masked] 
> > http://www1.ietf.org/mailman/listinfo/megaco
<http://www1.ietf.org/mailman/listinfo/megaco>  
> > 
> > _______________________________________________ 
> > Megaco mailing list 
> > [email-masked] 
> > http://www1.ietf.org/mailman/listinfo/megaco
<http://www1.ietf.org/mailman/listinfo/megaco>  
> 
> _______________________________________________ 
> Megaco mailing list 
> [email-masked] 
> http://www1.ietf.org/mailman/listinfo/megaco
<http://www1.ietf.org/mailman/listinfo/megaco>  

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