Subject: ContextId w/ALL

From: Chuong Nguyen <[email-masked]>
Date: Fri, 23 Mar 2001 18:03:22 -0600

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.

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:

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?

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.

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: Christian Groves <[email-masked]>
Date: Mon, 26 Mar 2001 15:54:45 +1000

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:
> I have not seen an wording added to v1 or Implementor Guide that
> clearly stated that

[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. )  

> Transaction = 1 {Context = * {AuditValue =  c4s1c1 {Audit { Media } }
> } }
> 
[CHG] This is not a new definition.

> 
> Transaction = 1 { O- Context = * {AuditValue =  c4s1c1 {Audit { Media
> } }  } ,

[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.

>                                                    W- Context = - {SC
> =  T1* or DS3* ; whatever the Forced syntax is{}  }}
> 
> Even though I specify a "W-", there will be terminations that are 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 :-).