Subject: Re: Subtract Command with wildcard Termination Name

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Jan 2000 16:11:43 -0500

Is the following what you want to do?

Transaction=1000{Context=*{AuditValue=T123}}
Reply = 1000{Context=2222{AuditValue=Context{T123}}

Should be

Transaction=1000{Context=*{AuditValue=T123{Audit{}}}

Reply=1000{Context=2222{AuditValue=T123()

or

Transaction=1000{Context=*{AuditValue=*}}
Reply = 1000{Context=2222{AuditValue=Context{T123},
                         Context=3333{AuditValue=Context{T222,T333},
                         Context=.....}

Should look similar to above

If yes, this is already taken into account by the current ABNF.

Chuong

Tom-PT Taylor wrote:

OK, this is the second comment I've had to this effect -- the other was
received privately.  The one question is whether we want a way to find out
what context a termination is in without subtracting it to find out, in
which case the audit response syntax I suggested might be considered.
Silence means we don't need this additional functiuonality.

        -----Original Message-----
From:  Rosen, Brian [SMTP:[email-masked]]
Sent:  Monday, January 24, 2000 10:10 PM
To:    Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
Subject:       RE: Subtract Command with wildcard Termination Name

        I think this is headed in the wrong direction.  Subtract of
wildcarded contextId was explicitly allowed for,
among other things, the response to a ServiceChange with mass out of service
operations pending.
The MGC must subtract all calls, and do it in a hurry.

        It is also useful in a wildcard Audit, with or without W-.

        So I think it is allowed, period.

        Brian

        -----Original Message-----
From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, January 24, 2000 10:06 AM
To: [email-masked]
Subject: Re: Subtract Command with wildcard Termiantion Name

        Your question has a couple of wider implications.  My first reaction
was to say this was an error, because in principle the MGC can always know
which context a termination is in, through audits if necessary.  Then I
checked out our audit response syntax and realized that the MGC cannot
determine the current context of a termination if it doesn't know it
already.

        I think the answer has to be that we change the production
auditOther to include the context ID.

        e.g.auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
terminationAudit RBRKT

        Then the answer to your original question is that it is an error.

                -----Original Message-----
From:   Sachin Mittal [SMTP:[email-masked]]
Sent:   Sunday, January 23, 2000 11:56 PM
To:    [email-masked]
Subject:       Subtract Command with wildcard Termiantion Name

                Hi!
     Here is a small query regarding the case where ContextID is "*" and
Termination Name is fully-specified. Does this implies that MGC intends to
Subtract the specific termination from
"whichever" context it appears in ? Or it is an error because a termination
can
exist only in one context and
ContextID = "*" for a specific termination is an error ?

                Regards
MadhuBabu

--

  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: Wed, 26 Jan 2000 15:39:08 -0600

The ABNF is

auditReply = (AuditValueToken / AuditCapToken) {contextAudit /
auditOther)

My example reply with contextAudit and your example reply with
auditOther.

The reason I used contextAudit because I am trying to follow 7.2.5 which
try to show how to audit
a context.
Look like both ways are correct.  How can we tell which one to use or
when to use
contextAudit vs auditOther?

Chuong

"Rosen, Brian" wrote:

>     > OK, this is the second comment I've had to this effect --
>     > the other was received privately.  The one question is
>     > whether we want a way to find out what context a
>     > termination is in without subtracting it to find out, in
>     > which case the audit response syntax I suggested might be
>     > considered.  Silence means we don't need this additional
>     > functiuonality.
>     >
>     >      I think this is headed in the wrong direction.
>     >      Subtract of wildcarded contextId was explicitly
>     >      allowed for,
>     >      among other things, the response to a ServiceChange
>     >      with mass out of service operations pending.
>     >           From: Tom-PT Taylor
>     >           [mailto:[email-masked]]
>     >           Your question has a couple of wider
>     >           implications.  My first reaction was to say this
>     >           was an error, because in principle the MGC can
>     >           always know which context a termination is in,
>     >           through audits if necessary.  Then I checked out
>     >           our audit response syntax and realized that the
>     >           MGC cannot determine the current context of a
>     >           termination if it doesn't know it already.
>     >
>     >           I think the answer has to be that we change the
>     >           production auditOther to include the context ID.
>     >
>     >           e.g.auditOther = EQUAL TerminationID LBRKT
>     >           CtxToken EQUAL ContextID  terminationAudit RBRKT
>     >
>     >           "whichever" context it appears in ? Or it is an
>     >           error because a termination can