Subject: [RE: [Megaco] Usage Of ContextId Wildcard]

From: Christian Groves <[email-masked]>
Date: Tue, 18 Sep 2001 11:15:59 +1000

I agree with Brian that we don't need such extensive changes. I'm not in
favour of updating * to include NULL for Audit. I'm not sure that we
need to point out specific error cases.

If we need anything I think all we need is a general statement to say
that in an error situation the MG returns the IDs that is sent to it
unless the MG can process enough of the transaction to determine the
correct IDs.

Christian

-------- Original Message --------
Subject: RE: [Megaco] Usage Of ContextId Wildcard
   Date: Mon, 17 Sep 2001 13:55:02 -0400
   From: "Rosen, Brian" <[email-masked]>
     To: "'Ian Leighton'" <[email-masked]>, [email-masked]
     CC: "'Christian Groves'" <[email-masked]>,Mark
         Klerer<[email-masked]>,"Russell-Laing,
         Andrew"<[email-masked]>

 The protocol change was one changing ALL to include NULL foraudit.I
don't see that we need such extensive wording changes in thetext. I
think editing the Annex L text to include this specific case,and noting
that the reply of a command with a wildcardedContextId may be the
original wildcarded ContextId when theerror 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]]
    >  > 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

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

---

From: Ian Leighton <[email-masked]>
Date: Tue, 18 Sep 2001 18:02:23 -0400

Hi Christian

I agree that "* to include NULL for Audit" should not be added.

Could you give an example of the text that you would add and
section that you would add it too?

I think that the number of questions concerning wildcard contextid
is evidence that the text is lacking when it comes how to process
wildcard ContextIds.  Basing implementation decisions on mailing
list threads is not a option unless specific references to the
spec are provided which clearly describe the protocol. In the case
of usage of wildcard contextId (ALL and CHOOSE) I don't
believe that these exist.

Since the problem with my proposal appears to the extent of the
changes, rather than dismissing them, I would opt for not
addressing 4 (from my list below) and address 2 by adding text
as described by Brian Rosen and/or Christian Groves.

Item 1 (Terminations in the NULL context) could be addressed
by adding the following;

"The ALL wildcard applies to the terminations that are available
in the Context specified in the Action."

This would restrict the contradictory statements that exist in
many commands. For example from the AuditValue command.

"If the wildcard matches more than one TerminationID, all possible
matches are attempted, with results reported for each one."

Item 3 (Multiple Commands and Context = *) could be addressed
by adding to 8.2.1 TransactionRequest the following.

"If the ContextId is a wildcard id (ie. ALL or CHOOSE),
 then the ContextIDs are determined with respect to the first
 command in the Action."

I would appreciate any comments/clarification/corrections.

Regards
Ian

---

From: Christian Groves <[email-masked]>
Date: Thu, 20 Sep 2001 14:33:05 +1000

Hello Ian,

Let me address the following:

1) Are terminations in the NULL context processed when commands 
   with Context=* and term=* are requested. 

Section 6.1.1 Specifies "ContextID. A wildcarding mechanism using two
types of wildcards can be used with ContextIDs.  The two wildcards are
ALL and CHOOSE.  The former is used to address ALL (except the NULL
context) Contexts at once in a command request and/or reply, while the
latter is used to indicate to a media gateway that it must create a
Context."

This is the general rule therefore ALL doesn't contain NULL so
termination is in the NULL context are not processed. I don't think
extra text is needed as it already stated.  

Section 8.2.2 Specifies: "The ContextID parameter must specify a value
to pertain to all Responses for the action.  The ContextID may be
specific, all or null."

This again is a general rule, I believe that the key phrase here is
"pertain to all Responses for the action". It allows specific, all or
null to be returned. If it is unclear what is to be returned. I believe
11.3 of the Implementors' Guide offers advice was is returned.

See above comment.

See also my comments CHG below.

> believe that these exist.

[CHG] Above are 2 references that I think can be used.

> matches are attempted, with results reported for each one."

[CHG] I think you need to clarify this by saying "The ALL wilcard for a
termination applies .....". 

>  then the ContextIDs are determined with respect to the first

[CHG] Look at 11.3 of the Implementors' guide for advice on returning
context IDs.

---

From: "J K Ramachandra" <[email-masked]>
Date: Thu, 20 Sep 2001 20:06:18 -0500

Hi,

Where can I get the latest MEGACO Annex G and Annex N documents?

Thanks for your time,

- J K Ramachandra

---

From: Ian Leighton <[email-masked]>
Date: Thu, 20 Sep 2001 12:55:06 -0400

Hi Christian

Thank you for your reply.

More comments below.

Regards
Ian

> extra text is needed as it already stated.

The problem is not the individual statements but that statements contradict

each other. Statements in 6.1.1and 8.1.2 (that indicate the ALL ContextID
does not include NULL) are contradicted by the following statement in
Add, Modify, Subtract, Move and AuditValue;

In essence an implementor must choose which statement takes precedence;

- do not include NULL in the reply because of what is stated in 6.1.1
and 8.1.2 or
- reply with NULL contextID because all terminations are checked and
some of the matching terminations are in the NULL context.

> 11.3 of the Implementors' Guide offers advice was is returned.

There is no dispute that the ContextId  pertains to the Responses
for the Action, it is that 2 possible ContextId could equally apply.
The contextId could be for the Context the termination is currently in
(eg. the NULL context) or the contextId of the request (ie. ALL).

> See above comment.

For me this is the most troubling problem. Even if I take the above
into consideration it appears to me that the following transaction

t = 1 { c = $ { A = t1/1 {...}, Add = $ {...} }}

could result in either of the following replies.

p = 1 { c = 1 {A = t1/1 {...}}, c = 2 {A = ephem/1 {...}}}
or
p = 1 { c = 1 {A = t1/1 {...}, {A = ephem/1 {...}}}

I believe that related problems exist for requests which include
ContextId = * and AuditValue = T1/*,Subtract = *.

I have not been able to find the reference but I recall a past
email(s) which indicated that a requester should be concise
in what is being requested. The current text can be interpreted
2 ways which makes being concise impossible when wildcard
ContextId are involved. Unless I'm missing something, section
8.2.1 needs to be clarified to identify how wildcard contextId
(ALL and CHOOSE) are processed especially when multiple
commands are included in an action.

more comments below.

> termination applies .....".

I would agree with that. The statement would then be

"The ALL wildcard for a termination applies to the terminations that are
available in the Context specified in the Action."

In my opinion this should be added to the Add, Modify, Subtract,
Move and AuditValue commands.

more comments below

> [CHG] Look at 11.3 of the Implementors' guide for advice on returning

Section 11.3 of the IG does not describe multiple commands per Action.

---

From: Christian Groves <[email-masked]>
Date: Mon, 24 Sep 2001 11:25:20 +1000

G'Day Ian,

Perhaps I've been working with this for too long but I don't really see
the problems that led to the misinterpretation of this. If others on the
list want to add some more examples to 11.3 if it aids intepretation of
what is returned then OK.

Christian

..snip..
> some of the matching terminations are in the NULL context.

[CHG] I really don't see the contradiction. You match the terminations
that are in scope of the provided ContextID, in this case ALL which does
not contain the NULL context. 

..snip..

> commands are included in an action.
[CHG] It cannot be your first example, because you have requested to
CHoose "?" one context. The context scopes the rest of the commands
under it. I thought this was rather well understood.

---

From: Ian Leighton <[email-masked]>
Date: Tue, 25 Sep 2001 09:28:41 -0400

Hi Christian

Why is there a reluctance to add clarifying text to the
base document?

Three comments below.

Regards
Ian

> what is returned then OK.

I don't think 11.3 is the best place unless the title is changed to indicate
something other than Audit.

> not contain the NULL context.

If the above statement (ie "match the terminations that
are in scope of the provided ContextID") existed in the
spec I would agree with you..

> under it. I thought this was rather well understood.

I whole heartedly agree that the second option is the
correct one but this is not my point. The point is the spec
could be interpreted as per example 1 because there is no
statements which indicate the contextId resulting from the
first command are used in subsequent commands.

---

From: Christian Groves <[email-masked]>
Date: Wed, 26 Sep 2001 16:00:16 +1000

Hello Ian,

Sect 8 states: "Transactions guarantee ordered Command processing.  That
is, Commands within a Transaction are executed sequentially". ContextID
is above the command level. Therefore you execute ContextID=? first, you
then process the commands under that context. ie. sequentially.

It all comes down to how you process the order of command processing.

I am reluctant to update the specification because I don't see alot of
other people complaining about the confusion in processing of commands
and I don't like to update existing approval specifications with things
that aren't absolutely needed. 

I won't contribute more on this. If other people want updates then its
up to the IG editor and others on the list to agree on updates then its
OK for me.

Christian