Subject: Re: Wildcard in ContextId

From: Chuong Nguyen <[email-masked]>
Date: Thu, 22 Feb 2001 13:40:12 -0600

Tom/Brian

Sorry for bringing this up again.

"Rosen, Brian" wrote:

> I understand your interest in a simpler answer, but simpler for
> whom?Generally, we try to make the MG implementation simpler, at the
> cost of,if necessary, complexity in the MGC.The design of the
> transaction/action/command/descriptor mechanismis tilted to make
> decode at the MG as simple as we can, and still getthe expressive
> power to achieve the goals of the protocol.

> We defined ALL as not including NULL so that it was possible todo
> clean up like Context=*{Subtract=*}.  That would not be possibleif ALL
> included NULL.

<cnn>  I am not sure where we define ALL as not including NULL.
              But I can live with it.  But it is kind of funny that ALL
does not mean all and we want to introduce "ANY"
              which does really mean all.
              By introducing "ANY" in v2 are we going to have some
backward compatability issue w/the range of
              in use contextId - 1 to 0xfffffffd?  Maybe we should start
out by reserving some of the contextId for future use.

               Your example of Subtract is already covered by the
following statement in the Implementator's Guide.
               It is specifically defining what it is meant to use
ALL in contextId for Subtract and for Subtract command
               only.  It is not saying anything about ALL as not
including NULL.

                    "ALL may be used as the ContextID as well as the
TerminationId in Subtract, which would have the
                      effect of deleting all contexts, deleting all
ephemeral terminations, and returning all physical terminations
                      to NULL context.  Subtract of termination from the
NULL context is not allowed."

> That means no single command can affect terminations in NULL as well
> as terminations other contexts.

<cnn>  You don't want a single command to affect terminations in
NULL and others context?
               Does that mean you would oppose adding "ANY"  in v2?

> It may well be that in hindsight we discover that it was a poor
> choice,but it's done now.

<cnn>  What is the poor choice here?

> It is trivial to send two commands.  It is non trivial to have special
> caserules for various combinations of ALL, CHOOSE and NULL dependingon
> whether it's the MG or MGC sending, the command being executed,and the
> state of the MG.  It is even more difficult to evaluate combinationsof
> ALL in ContextID and different commands so that you get some
> reallycompact notation to do these kinds of things.  Much better to
> not haveany contextual dependence on evaluation of ALL in ContextId on
> commandand/or terminationID.

<cnn>  One is going to have to evaluate combinations of ALL in ContextID
and different commands.
               Also there is already precedent that there will be
limitations on what is valid to use for ContextID for each command.

                For example, even though it is not explicitly stated
that ContextID cannot be "ALL" in a MOVE command,
                it is clear by other restriction that ContextID cannot
be "ALL" in a MOVE command.
                       "The Context to which the Termination is moved is
indicated by the target ContextId in the Action."

So back to my original question of the need to use 2 ServiceChange
commands to take a wildcarded TerminationId
out or in service due to ContextId parameter in ServiceChange command.
We went over this issue back in early 2000.  But I guess Tom did clarify
it for single termination
but left out wildcard terminationId.
I think we need to go back to Sachin's proposal that ContextId should
not have any importance in ServiceChange.

Now somehow we drag in the issue of ALL not including NULL which somehow
was derived from trying to do
a Subtract ALL.

Date:         Tue, 1 Feb 2000 10:17:16 -0500
                  Reply-To:     Tom-PT Taylor
<[email-masked]>
                  Sender:       "Media Gateway Control (megaco)"
                                <[email-masked]>
                  From:         Tom-PT Taylor
<[email-masked]>
                  Subject:      Re: Importance of ContextID in
ServiceChange command
                  X-To:         [email-masked]
                  Content-Type: multipart/alternative;

                  The phrasing I put in my message "Issue Scorecard" was
that the MGC "should"
                  send the right contextID when a single termination is
involved, implying
                  that the MG could not count on it, but might be able
to use it to speed up
                  processing.

                  > -----Original Message-----
                  > From: Sachin Mittal [SMTP:[email-masked]]
                  > Sent: Tuesday, February 01, 2000 12:00 AM
                  > To:   [email-masked]
                  > Subject:      Re: Importance of ContextID in
ServiceChange command
                  >
                  >
                  >
                  > I said that because in case of Graceful and Forced
whether from MG or MGC,
                  > the
                  > MG
                  > does not clear the context by itself and the
subtract from MGC does that.
                  > So MG
                  > has nothing to do with
                  > contextID (Termination is specified or wildcarded).
For restart the basic
                  > assumption is that
                  > it is sent for terminations which are out-of-service
???. And
                  > Disconnected,
                  > Handoff, Failover
                  > methods are for root termination.
                  >
                  > Thus if MGC provides contextid or not doesn't matter
to MG. Do you mean to
                  > say
                  > that if
                  > MGC provides a wrong contextid the MG will DISCARD
ServiceChange just
                  > because
                  > contextid is wrong !!! (so need of checking
contextid/ no meaning of
                  > contextid
                  > in servicechange)
                  >
                  > In my opinion so called "implementation issues"
which are in fact a MUST
                  > to
                  > consider
                  > for each implementation should find there way into
the document.
                  >
                  >
                  >
                  >
                  > Chuong Nguyen <[email-masked]> on
02/01/2000 12:28:45 AM
                  >
                  > Please respond to Chuong Nguyen
<[email-masked]>
                  >
                  > To:   [email-masked]
                  > cc:    (bcc: Sachin Mittal/HSS)
                  >
                  > Subject:  Re: Importance of ContextID in
ServiceChange command
                  >
                  >
                  >
                  >
                  > It will depends on the scenario.  Therefore it is an
implementation
                  > issue.  Thus it should not
                  > be a requirement to provide contextId.
                  > For example, what if someone wants to take a range
of terminations out
                  > of service via wildcards.
                  > The contextId would be different for that range of
terminations.
                  >
                  > For an individual termination, it should be allowed
but not mandatory.
                  > But simplicity is better here.
                  >
                  > Chuong
                  >
                  > Tom-PT Taylor wrote:
                  >
                  > >
                  > >
                  > > I've thought about this a bit more, and I think
it's wrong.  Where
                  > > ServiceChange applies to an individual termination
rather than ROOT,
                  > > the sender should provide the contextID of the
context in which the
                  > > termination currently exists.  This makes it
easier for the other end
                  > > to process the command.
                  > >
                  > >      -----Original Message-----
                  > >      From:  Sachin Mittal
[SMTP:[email-masked]]
                  > >      Sent:  Monday, January 31, 2000 2:54 AM
                  > >      To:    [email-masked]
                  > >      Subject:       Re: Importance of ContextID in
ServiceChange
                  > >      command
                  > >
                  > >
                  > >      Need to add this in text. Somehow missed in
V14.
                  > >
                  > >
                  > >
                  > >      Tom-PT Taylor <[email-masked]> on
01/28/2000 02:28:57
                  > >      AM
                  > >
                  > >      Please respond to Tom-PT Taylor
<[email-masked]>
                  > >
                  > >      To:   [email-masked]
                  > >      cc:    (bcc: Sachin Mittal/HSS)
                  > >
                  > >      Subject:  Re: Importance of ContextID in
ServiceChange command
                  > >
                  > >
                  > >
                  > >      Good point.
                  > >
                  > >      > -----Original Message-----
                  > >      > From: Sachin Mittal
[SMTP:[email-masked]]
                  > >      > Sent: Thursday, January 27, 2000 4:07 AM
                  > >      > To:   [email-masked]
                  > >      > Subject:      Importance of ContextID in
ServiceChange command
                  > >      >
                  > >      > HI all
                  > >      >
                  > >      > It should be mentioned somewhere in the
text that there is no
                  > >      > siginificance of
                  > >      > ContextID in case of ServiceChange Command.
The ServiceChange
                  > >      command
                  > >      > is for terminations and no validation is
done on ContextID
                  > >      should be done.
                  > >       << File: Internet HTML >>
                  > >
                  > --
                  >   Alcatel USA, Inc             Internet:
[email-masked]
                  >   1000 Coit Road Plano, Texas 75075
Phone:    (972) 519-4613
                  >   **** The opinions expressed are not those of
Alcatel USA, Inc ****

>  I'd LIKE to make notation compact, but not at theexpensive of MG
> implementation complexity.Brian
>
>      -----Original Message-----
>      From: Chuong Nguyen [mailto:[email-masked]]
>      Sent: Tuesday, January 30, 2001 1:43 PM
>      To: [email-masked]
>      Subject: Re: Wildcard in ContextId
>      Brian
>
>      I was looking for a simpilier answer.
>
>      For ServiceChange command, it seems like ContextId is of no
>      value.
>      MG just wants to tell MGC that a T1 has gone out of service.
>
>      MGC just wants to tell MG that - Ok I got the msg that the
>      T1 is out of service.
>
>      It does not matter whether some of the T1 channels are in
>      some active Contexts
>
>      Because of NULL is not in ALL, now we have to say in the
>      NULL context
>      any termination matching that T1 naming pattern is out of
>      service.
>      Also in the rest of the active contexts, any termination
>      matching that T1 naming pattern
>      is out of service.
>
>      I don't know of any other scenario where ContextId would
>      apply to ServiceChange.
>
>      The NULL is not in ALL came from "wildcard Subtract ALL"
>      discussion way back.
>      I think it went like - one can't Subtract a termination from
>      NULL.
>      So all of a sudden ALL does not include NULL because it is
>      not valid to subtract
>      termination from NULL.
>      But it would have been better to say that when Subtract
>      w/ALL, it only means
>      subtract all terminations from active contexts and has
>      nothing to be w/NULL context.
>
>      It is always going to be confusing to have ALL not meaning
>      all.
>      So now one has to send 2 commands - one for NULL and one for
>      ALL
>      even though we have a wildcard in the terminationId.
>
>      So say if I want to locate a termination, do I have to send
>      2 commands -
>      w/ContextID = NULL and ContextID = ALL?
>      To tell the MG, look in the NULL context and look in all the
>      active contexts?
>
>
>      Thanks
>      Chuong
>
>
>
>
>
>      "Rosen, Brian" wrote:
>
>     > Since Null is not in *, if a/b/c/d2 is not in Null
>     > Context=- would not cover it.You will need to send two
>     > serviceChange commands, one for null, one for ALL.Thus
>     > your response #1 is what you getBrian
>     >
>     >      -----Original Message-----
>     >      From: Chuong Nguyen
>     >      [mailto:[email-masked]]
>     >      Sent: Thursday, January 25, 2001 4:32 PM
>     >      To: [email-masked]
>     >      Subject: Re: Wildcard in ContextId
>     >
>     >
>     >      Hi All,
>     >
>     >      The following from MG to MGC:
>     >
>     >      Context = - {[W-] ServiceChange = a/b/c/d*
>     >      {Method=Forced}}
>     >
>     >      where a/b/c/d* represents a T1.
>     >
>     >      What should the ContextId be in the Request "-"
>     >      or "*"?
>     >
>     >      What should the reply be?
>     >
>     >
>     >      1)  Context = - {ServiceChange = a/b/c/d*}
>     >
>     >      2)  Context = * {ServiceChange = a/b/c/d*}
>     >
>     >      3) Context = - {ServiceChange=
>     >      a/b/c/d1},              channel 1 of T1 that is
>     >      in the NULL context
>     >           Context = 100 {ServiceChange =
>     >      a/b/c/d2},         channel 2 of T1 that is in
>     >      context 100.
>     >
>     >
>     >
>     >          so on for each channel since they are in
>     >      different Context
>     >
>     >      Should or does ContextID have any significant
>     >      w/ServiceChange from MG?
>     >
>     >
>     >
>     >      Thanks
>     >      Chuong
>     >
>     >
>     >
>     >
>     >
>     >      Sachin Mittal wrote:
>     >
>     >      > If the basic philosophy of  "context parsing to
>     >      > be done independently of the
>     >      > command parsing" is applied strictly to the
>     >      > example being discussed or that
>     >      > given by Mike
>     >      > below the ContextId = * gives me all contexts
>     >      > that exist and thus the reply
>     >      > should contain all
>     >      > context IDs.
>     >      >
>     >      > "Your example would be better expressed as two
>     >      > actions with
>     >      > one command each rather than one action with
>     >      > two commands"
>     >      > Yes I agree to that it should be two actions,
>     >      > but then we need to specify
>     >      > somewhere
>     >      > in implementors' guide that MG should not
>     >      > depend on this but MGC should set it
>     >      > right
>     >      > (give two actions rather than one)
>     >      >
>     >      > Sachin
>     >      >
>     >      > "Rosen, Brian" <[email-masked]> on
>     >      > 01/19/2001 06:28:03 PM
>     >      >
>     >      > To:   Sachin Mittal/HSS@HSS,
>     >      > [email-masked]
>     >      > cc:
>     >      >
>     >      > Subject:  RE: Wildcard in ContextId
>     >      >
>     >      > I think this makes implementations more
>     >      > difficult for no significant
>     >      > gain.  What you would need to do is to do all
>     >      > the matching for all the
>     >      > commands,
>     >      > rather than process one command at a time.  I'm
>     >      > already reluctant to require
>     >      > that context=* is evaluated on the first
>     >      > command, since the basic mechanism
>     >      > was supposed to allow the context parsing to be
>     >      > done independently of the
>     >      > command parsing.  Your example would be better
>     >      > expressed as two actions with
>     >      > one command each rather than one action with
>     >      > two commands.
>     >      >
>     >      > Brian
>     >      >
>     >      > > -----Original Message-----
>     >      > > From: Sachin Mittal
>     >      > [mailto:[email-masked]]
>     >      > > Sent: Thursday, January 18, 2001 11:54 PM
>     >      > > To: [email-masked]
>     >      > > Subject: Re: Wildcard in ContextId
>     >      > >
>     >      > >
>     >      > > If we remove the complication of W- from the
>     >      > example
>     >      > > >     Context = * {
>     >      > > >         W-Audit = * { ... }
>     >      > > >         Subtract = T1
>     >      > > >     }
>     >      > > and change it to
>     >      > > >     Context = * {
>     >      > > >         Subtract = T2,
>     >      > > >         Subtract = T1
>     >      > > >     }
>     >      > > where T2 is in ContextID=2 and T1 is in
>     >      > ContextID=1 (say)
>     >      > > the choice of response #2 is incorrect. It
>     >      > doesn't make sense
>     >      > > to tell MGC that in Context =2 the subtract
>     >      > of T1 has failed.
>     >      > > The general
>     >      > > idea "Context=* matches Contexts with
>     >      > > terminationIDs that match the FIRST action
>     >      > terminationId"
>     >      > > becomes invalid for this very common case
>     >      > where MGC doesn't
>     >      > > know the Contexts
>     >      > > in which T1 , T2 exists but wants to subtract
>     >      > them wherever
>     >      > > they exist.
>     >      > >
>     >      > > Sachin
>     >      > > Hughes Software Systems
>     >      > >
>     >      > >
>     >      > >
>     >      > >
>     >      > >
>     >      > > "Rosen, Brian" <[email-masked]> on
>     >      > 01/17/2001 12:11:37 AM
>     >      > >
>     >      > > Please respond to "Rosen, Brian"
>     >      > <[email-masked]>
>     >      > >
>     >      > > To:   [email-masked]
>     >      > > cc:    (bcc: Sachin Mittal/HSS)
>     >      > >
>     >      > > Subject:  Re: Wildcard in ContextId
>     >      > >
>     >      > >
>     >      > >
>     >      > >
>     >      > > I think Context=* gets you multiple replies.
>     >      > > I think processing of Context=* occurs before
>     >      > consideration
>     >      > > of terminationIds given the current text.
>     >      > >
>     >      > > I like your example.  I'd choose #2 as the
>     >      > correct response.
>     >      > >
>     >      > > We could consider trying to make it better,
>     >      > slightly,
>     >      > > by specifying that Context=* matches Contexts
>     >      > with
>     >      > > terminationIDs that match the FIRST action
>     >      > terminationId.
>     >      > > Then you clearly would get errors in your
>     >      > example, but
>     >      > > the common case would work better.
>     >      > >
>     >      > > Brian
>     >      > >
>     >      > > > -----Original Message-----
>     >      > > > From: Mike Broome
>     >      > [mailto:[email-masked]]
>     >      > > > Sent: Tuesday, January 16, 2001 12:47 PM
>     >      > > > To: Rosen, Brian
>     >      > > > Cc: [email-masked]
>     >      > > > Subject: Re: Wildcard in ContextId
>     >      > > >
>     >      > > >
>     >      > > > I'm not sure what the syntax "Context-W=*"
>     >      > means.  (That's might be
>     >      > > > your point:  it is not valid syntax.)
>     >      > > >
>     >      > > > When using Context=* and W- on a command,
>     >      > should the reply be
>     >      > > > one action
>     >      > > > or multiple actions?  Section 7.3 of the
>     >      > Implementors' Guide defines
>     >      > > > this scenario as returning one action with
>     >      > Context=* in the
>     >      > > reply.  Is
>     >      > > > this still the case?  Or are you saying
>     >      > that Context=* in a request
>     >      > > > should always be expanded into multiple
>     >      > replies?
>     >      > > >
>     >      > > > What happens for a more complicated action
>     >      > like the following:
>     >      > > >
>     >      > > >     Context = * {
>     >      > > >         W-Audit = * { ... }
>     >      > > >         Subtract = T1
>     >      > > >     }
>     >      > > >
>     >      > > > This is a somewhat ambiguous command for an
>     >      > MGC to send, but
>     >      > > > how should
>     >      > > > it be handled?  Section 7.3 of the
>     >      > Implementors' Guide only has an
>     >      > > > example for a single W- command in an
>     >      > action.  I see three
>     >      > > > possibilities
>     >      > > > here:
>     >      > > >
>     >      > > > 1. Send back an error because the
>     >      > termination specifier
>     >      > > doesn't match
>     >      > > > between the two commands (ALL and
>     >      > specific).
>     >      > > >
>     >      > > > 2. Expand the Context=* and send back
>     >      > multiple replies,
>     >      > > with an error
>     >      > > > descriptor for the Subtract command in all
>     >      > the replies except the
>     >      > > > Context that contains T1.
>     >      > > >
>     >      > > > 3. Internally, split the action into
>     >      > multiple actions with
>     >      > > > the commands
>     >      > > > grouped based on the termination specifier
>     >      > and W-.  For the
>     >      > > example I
>     >      > > > gave, we'd end up with two actions:
>     >      > > >
>     >      > > >     Context = * {
>     >      > > >         W-Audit = * { ... }
>     >      > > >     }
>     >      > > >
>     >      > > >     Context = * {
>     >      > > >         Subtract = T1
>     >      > > >     }
>     >      > > >
>     >      > > > Any comments?
>     >      > > >
>     >      > > > Thanks,
>     >      > > > Mike
>     >      > > >
>     >      > > > On Fri, Jan 12, 2001 at 03:54:43PM -0500,
>     >      > Rosen, Brian wrote:
>     >      > > > > You can't say Context-W=*, or anything
>     >      > equivalent.
>     >      > > > >
>     >      > > > > Therefore, when you use Context=*, you
>     >      > are going to get back
>     >      > > > > more than one action, and there is no way
>     >      > to indicate that
>     >      > > > > you only wanted one action.
>     >      > > > >
>     >      > > > > It is valid to use Context=* when you use
>     >      > W-.
>     >      > > > >
>     >      > > > > If the command has an error, you could
>     >      > get back Context=*,
>     >      > > > > so I don't think I've contradicted the
>     >      > Error response to CHOOSE.
>     >      > > > >
>     >      > > > > Brian
>     >      > > > >
>     >      > > > > > -----Original Message-----
>     >      > > > > > From: Mike Broome
>     >      > [mailto:[email-masked]]
>     >      > > > > > Sent: Friday, January 12, 2001 3:19 PM
>     >      > > > > > To: [email-masked]
>     >      >
>     >      > > > > > Subject: Re: Wildcard in ContextId
>     >      > > > > >
>     >      > > > > >
>     >      > > > > > Brian,
>     >      > > > > >
>     >      > > > > > When you say "wildcard response" do you
>     >      > mean there is no
>     >      > > > way to get a
>     >      > > > > > reply that contains "Context = *" or do
>     >      > you mean that it is
>     >      > > > > > not valid to
>     >      > > > > > use "W-" (the wildcard response
>     >      > indicator) on any of the
>     >      > > > > > commands in an
>     >      > > > > > action where the ContextID is
>     >      > wildcarded?
>     >      > > > > >
>     >      > > > > > The first interpretation is at odds
>     >      > with the recent
>     >      > > > discussion in the
>     >      > > > > > thread "Error response to a CHOOSE".
>     >      > (It also would make the
>     >      > > > > > change in
>     >      > > > > > 6.21 in the IG that adds support for
>     >      > returning ALL as the
>     >      > > > > > ContextID for
>     >      > > > > > a transaction no longer needed, right?)
>     >      >
>     >      > > > > >
>     >      > > > > > The second interpretation would make an
>     >      > action like the
>     >      > > > following --
>     >      > > > > > with both ContextID and TerminationID
>     >      > wildcarded and a W- on
>     >      > > > > > the command
>     >      > > > > > -- invalid:
>     >      > > > > >
>     >      > > > > >     Context = * {
>     >      > > > > >         W-Audit = * { ... }
>     >      > > > > >     }
>     >      > > > > >
>     >      > > > > > If the above action IS valid, would the
>     >      > Reply have
>     >      > > > "Context = *" or
>     >      > > > > > would there be a separate action reply
>     >      > for every context?  My
>     >      > > > > > preference
>     >      > > > > > would be to have "Context = *"
>     >      > indicating the ContextID is a
>     >      > > > > > don't care
>     >      > > > > > (similar to what was discussed in the
>     >      > "Error response
>     >      > > to a CHOOSE"
>     >      > > > > > thread).
>     >      > > > > >
>     >      > > > > > Thanks,
>     >      > > > > > Mike
>     >      > > > > >
>     >      > > > > >
>     >      > > > > > On Fri, Jan 12, 2001 at 08:21:58AM
>     >      > -0500, Rosen, Brian wrote:
>     >      > > > > > > Wildcards are allowed in ContextId.
>     >      > There is no way to get a
>     >      > > > > > > wildcard response if you use a
>     >      > wildcard ContextId.
>     >      > > > > > > We should probably point that out
>     >      > somewhere.
>     >      > > > > > >
>     >      > > > > > > Brian
>     >      > > > > >
>     >      > > >
>     >      > >
>     >
>     >      --
>     >        Alcatel USA, Inc             Internet: [email-masked]
>     >        1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>     >        **** The opinions expressed are not those of Alcatel USA, Inc ****
>     >
>     >
>     >
>      --
>        Alcatel USA, Inc             Internet: [email-masked]
>        1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****