Subject: [Fwd: [Megaco] Wildcard in ContextId]

From: "Chuong N. Nguyen" <[email-masked]>
Date: Thu, 06 Sep 2001 16:16:35 -0500

Reposting this due to

Your mail to 'Megaco' with the subject:

    Re: [Megaco] Wildcard in ContextId

Is being held until the list moderator can review it for approval.

The reason it is being held:

    Message body too long (>40k)

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.

"Chuong N. Nguyen" wrote:

>
> Tom
>
> We definitely need this clearly stated in the IG.
>
>
> But let me simplifies the transaction and ask again what the reply
> should be.
>
> Transaction = 1 {
>     Context = * {
>         AuditValue = T1/2 { ... } }}
>
> where T1/2 is in the NULL context.
>
> Also your  previous email response to a similar question and what
> seems to be your agreement
> to Kapil's intepretation
>
> Subject:
>            Re: Wildcard in ContextId
>        Date:
>            Thu, 1 Feb 2001 09:27:48 -0500
>       From:
>            Tom Taylor <[email-masked]>
>    Reply-To:
>            Tom-PT Taylor <[email-masked]>
>  Organization:
>            Nortel Networks
>         To:
>            [email-masked]
>   References:
>            1
>
> I think Chuong's inference is right.  An ANY placeholder as you
> propose
> it is an attractive v2 option.  In the meantime, the workaround is
> that
> the MGC has to be precise in its commands, giving the exact context
> for
> each termination to be subtracted.
>
> Kapil Nayar wrote:
> >
> > Hi
> >
> > Taking a clue from Chuong's example,
> > Context = * { Subtract = a/b/c/t123* } or Context = * { Subtract = *
> }
> > may result in a large number of command replies with error
> descriptors.
> >
> > We may all agree that the reasonable way to handle this is to
> resolve the
> > contexts and then resolve the terminations in those contexts, which
> is
> > against the assumption that context ids are resolved based upon the
> first
> > command in the action.
> >
> > Observing this thread of discussion, I wondered if we have ever
> thought
> > of a wildcarded option ANY(?) for context id in the protocol
> > (in addition to "ALL"(*), "CHOOSE"($) and "NULL"(-) existing in the
> protocol)
> > (ANY may refer to any existing context including NULL but doesn't
> specifically
> > refer to any one or all context ids).
> >
> > The ANY context id :
> > -    Cannot be partially wildcarded.
> > -    May be actively used for Subtract command with wildcarded
> termination
> id.
> > -    in Audit Value (termination wild carded) - audit of all
> matching
> >      terminations (even in NULL context).
> > Since, ANY would resolve to any (all including NULL) context ids,
> its usage
> > can be restricted to avoid any further confusion.
> >
> > Revisiting the examples sighted in this thread:
> >
> > Context = ? { Subtract = T2, Subtract = T1 }
> > Subtract T2 and T1 from there respective contexts without any need
> to return
> > error
> > descriptor from the first or the second command execution.
> >
> > Context = ? {Subtract = a/b/c/t123*}
> > Above can also be handled the same way.
> >
> > Context = ? { W-Audit = * { ... }, Subtract = T1 }
> > This would return the audit results for all the terminations and
> successfully
> > subtract
> > the termination T1 from its context without returning error
> descriptor.
> >
> > Any comments ?
> >
> > -Kapil Nayar
> > Hughes Software Systems
> >
> > Chuong Nguyen <[email-masked]> on 02/01/2001 05:20:19
> AM
> >
> > Please respond to Chuong Nguyen <[email-masked]>
> >
> > To:   [email-masked]
> > cc:    (bcc: Kapil Nayar/HSS)
> >
> > Subject:  Re: Wildcard in ContextId
> >
> > Just to make everything really clear.
> > The second command failed because the first command passed thus
> locking the
> > contextId
> > (said at 100).  The second command is executed based on this
> contextId=100
> and
> > not
> > the contextId=ALL.  Since contextId 100 did not contain the second
> termination,
> > the second
> > command failed.
> >
> > Thus leading to the conclusion that ContextId is always tied to
> first
> command.
> >
> > Does all these  discussions break the following
> > Context = * {Subtract = a/b/c/t123*} since t1234 might be in a
> different
> context
> > than t12345?
> >
> > because isn't the above a condensed version of the following
> > Context = *{Subtract = a/b/c/t1231, Subtract = a/b/c/t1232
> .....,Subtract =
> > a/b/c/t123n}
> > which will return error after the second Subtract if a/b/c/t1232 is
> not in
> the
> > same
> > context as a/b/c/t1231 based on the ongoing discussion.
> >
> > Chuong
> >
> > Tom Taylor wrote:
> >
> > > You return the contextID which worked for the first command.  My
> best
> guess at
> > the error for the second command is 433
> > > TerminationID is already in a context, as the least misleading
> possibility.
> > This very clearly a case where command order matters
> > > and is respected, since the first command succeeds and the second
> fails as
> a
> > result.
> > >
> > >

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