Subject: RE: ContextId w/ALL

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 26 Mar 2001 09:27:54 -0500

I'll confirm that "ALL" specifically excludes the NULL context and always
has.

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, March 26, 2001 12:55 AM
> To: Chuong Nguyen
> Cc: megaco
> Subject: Re: ContextId w/ALL
> 
> 
> Hello Chuong,
> 
> Please see my answers below. NULL not being in ALL has been 
> part of the
> protocol and not something which was "newly" made up. The use 
> of Context
> ALL is not something that is encouraged because as you have stated you
> get into some weird permutations. Move is the only place its really
> talked about being used with a command. None of the issues 
> you bring up
> break an implementation. They may be difficult for some vendors to
> implement but some others don't have this problem. I don't 
> feel that any
> change is warranted in the Implementors' Guide. 
> 
> Regards, Christian
> 
> Chuong Nguyen wrote:
> > 
> > Hi Tom/Brian
> > 
> > I am going to try one more time to see if "ALL" can really be all as
> > originally intended.
> > I have not seen an wording added to v1 or Implementor Guide that
> > clearly stated that
> > "ALL" does not include NULL.
> 
> [CHG] In H248v1 chp 7.2.3 it states "ALL may be used as the 
> ContextID as
> well as the TerminationId in a Subtract, which would have the 
> effect of
> deleting all contexts, deleting all ephemeral terminations, and
> returning all physical terminations to Null context." Now by 
> using logic
> ALL doesn't mean NULL because you can't delete NULL and put NULL into
> NULL.
> 
> In H.248v1 chp 7.2.5 it states "AuditValue results depend on the
> Context, viz. specific, null, or wildcarded.  (Note that ContextID All
> does not include the null Context. )  
> 
> > 
> > I have come up w/another command that has become awkward to 
> implement.
> > 
> > I just want to know what is the terminationState for the specified
> > terminationId by using
> > AuditValue:
> > 
> > In the past, I could have just done the following:
> > 
> > Transaction = 1 {Context = * {AuditValue =  c4s1c1 {Audit { 
> Media } }
> > } }
> > 
> > The Reply for ContextId is either an active ContextId or NULL.
> > 
> > But with the new definition of "ALL" not being all, I have to do the
> > following:
> [CHG] This is not a new definition.
> 
> > 
> > Transaction = 1 { O- Context = * {AuditValue =  c4s1c1 
> {Audit { Media
> > } }  } ,
> >                                   Context = - {AuditValue =  c4s1c1
> > {Audit { Media } }  }}
> > 
> > Thus the replies can be
> > 1) Context "*" result in error code 411.  Thus Context "-" 
> returns Ok.
> > 
> > 2) Context "*" returns active contextId.  So what does the second
> > AuditValue returns?
> 
> [CHG] You really should be using the correct contextID for the
> termination. The MGC should know whether or not the termination is in
> NULL or a specific context. If the termination doesn't exist in the
> context you get back an error code.
> 
> > 
> > 
> > Also as I had stated before ServiceChange for a T1 or DS3 
> going OOS is
> > also being made
> > complicated by (same problem when they switch back to IS)
> > 
> >           Transaction = 1 { O- W- Context = * {SC =  T1* or DS3* ;
> > whatever the Forced syntax is{}  } ,
> >                                                    W- 
> Context = - {SC
> > =  T1* or DS3* ; whatever the Forced syntax is{}  }}
> > 
> > instead of one simple ServiceChange command w/the Context as a don't
> > care.
> > 
> > Even though I specify a "W-", there will be terminations that are in
> > the NULL context
> > so the reply will contain an Error Descriptor for each 
> termination in
> > the NULL context.
> > Same goes for the next SC command w/context NULL.  There will be an
> > Error Descriptor
> > for each termination not in the NULL context.
> > 
> > Furthermore, if one has a non-robust implementation where string
> > compare is used to
> > handle wildcard termination, that application has to perform the
> > string compare twice.
> 
> [CHG] Bad luck get a better implementation :-).
> 
> > 
> > Then for MOVE, one can't really use a Context of "ALL".
> > 
> > So far I see two events that caused "ALL" not to be all.
> > 1) The additon of Subtract "ALL".
> >      But the text already stated that one cannot subtract 
> termination
> > from NULL.
> >       It doesn't mean that "ALL" does not include NULL.  It 
> just means
> > that all terminations in
> >       use will be returned to the NULL context.
> > 
> > 2) The need to "apply" something to all terminations but 
> not necessary
> > to terminations in the
> >       NULL context.  I have to see a real example to 
> justify changing
> > "ALL" to not mean all
> >       because of this.
> >       If the terminations are already in active contexts, applying
> > something to all terminations
> >       in active contexts could affect certain calls in progress or
> > established calls.
> >      Therefore highly unlikely
> >       Therefore one would probably apply on certain active contexts.
> > 
> >       If one wants to apply something to all terminations in the
> > NULL context, it can already be
> >        done by specifying NULL and termination=ALL.
> > 
> > Definitely having a new token for active contexts is desirable.
> > But not ANY.  Since we have NULL and ALL already, we just need
> > INUSE/ACTIVE.
> > Of course that can wait until v2.  But maybe not.
> > 
> > So Tom/Brian please give this issue some more thoughts and clearly
> > stated what
> > ever decision you decide in the Implementor Guide.
> > 
> > thanks
> > Chuong
> > 
> > 
> > --
> >   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 ****
> > 
> >
>

---

From: Chuong Nguyen <[email-masked]>
Date: Mon, 26 Mar 2001 08:54:34 -0600

Ok.  I concede.
But a few comments/questions below

Tom-PT Taylor wrote:

>
>
> I'll confirm that "ALL" specifically excludes the NULL context and
> always has.
>
>

<cnn>  So we are letting 1 command behavior defines what
context=ALL means.
              And it is up to the user to extract this definition from
"logic" applies to a very
              special application of Subtract which if an implementor
never uses.
             Therefore, that implementor will never arrives at the
conclusion of what context
              ALL really mean.

> > does not include the null Context. )

<cnn>  In the IG the following was added in Section 6.34 of IG

              "All        Specific                  (Non-null) ContextId
in which the Termination currently exits."

             How do I intepret the following original text which is
still present in the Standard?
             (I am pretty sure this originally include both active
context and NULL.
             Otherwise the above addition to IG wouldn't need to clarify
that only "(Non-null)"
              context is returned.)

             "All         wildcard                 Audit of all matching
Terminations and the Context to which
                                                                they are
associated.

> > > 2) Context "*" returns active contextId.  So what does the second

<cnn>  I would still like to know what error code should be return for
#2 above?

> > context you get back an error code.

<cnn>  Said MGC does not know due to lost info.  That is why the
Standard defined
              the AuditValue table that shows how an MGC can find out
the context and
              termination association info.

--
  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 ****