Subject: Add with wildcard termination ID

From: Sachin Mittal <[email-masked]>
Date: Mon, 9 Oct 2000 13:43:28 +0530

Suppose there are two terminations in MG named "abcd" and "abce"
and MGC sends an ADD as
CtxID=$ ADD TermID=abc*
Now MG is able to create a Context and successfully ADD "abcd" in it, but
ADDing of "abce" fails (say because of "abce" being "outofservice")

What ContextID will be used in the response for the termination "abce":
1. $
2. The allocated ContextID for "abcd"

Sachin

---

From: Sachin Mittal <[email-masked]>
Date: Wed, 11 Oct 2000 10:23:15 +0530

Now that it is understood that abc* may Add more than one termination and an
"outofservice"
termination can't be Added, what should an MG do when it receives ADD with
termination abc*
and CtxID = $ and MG is able to add abcd in CtxID say 1 but fails to Add other
termination say
abce ? Should MG send the response of Add of abce using CtxID = $ or using CtxID
that
is allocated.

Sachin

Chuong Nguyen <[email-masked]> on 10/10/2000 11:56:24 PM

Please respond to Chuong Nguyen <[email-masked]>

To:   [email-masked]
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Add with wildcard termination ID

Section 7.2.1 there is the following statement:

"Add SHALL NOT be used on a Termination with a serviceState of "OutofService"."

So I assume that MG should return an error on this ADD.

Chuong

Kevin Boyle wrote:

> It seems to me that if you can only add one termination per command, then
> use of the ALL (*) wildcard is not allowed for Add.  CHOOSE ($), however,
> would be acceptable.  There are other commands where these kinds of
> restrictions are already expressed, so why not add one for Add in the
> Implementer's Guide?
>
> It would also seem to me that if a termination is OOS, then adding it is not
> allowed.  Once again, somthing for the Implementer's Guide?
>
> Kevin
>
> "Rosen, Brian" wrote:
>
> > First of all, an Add only can add one termination per command,
> > so Add=abc* would only add abcd.  Pressing on, if, for
> > example, abcd was already in a context, then the
> > error would be in $ context, and would indicate no terminations
> > matched, I suppose.
> >
> > We might want to think about whether outofservice really causes
> > a no terminations matched situation.  On the one hand, adding
> > an out of service termination makes no sense.  On the other hand
> > auditing one does.  So does the matching logic work differently
> > for Audit than it does for Add?  I would think it shouldn't,
> > thus we have a quandry.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Sachin Mittal [mailto:[email-masked]]
> > Sent: Monday, October 09, 2000 4:13 AM
> > To: [email-masked]
> > Subject: Add with wildcard termination ID
> >

--
  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: "Rosen, Brian" <[email-masked]>
Date: Thu, 12 Oct 2000 10:40:19 -0400

Maybe I was the dense one.  I didn't think we needed to update the text,
just the nonsense I was spouting.  I don't think Add=abc* is all that
useful.
Maybe we should leave it as it is and change in in CS2, but I could also
support
removing the restriction.

Some more explanations, possibly with examples in the Implementer's Guide
would be nice.

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, October 11, 2000 11:54 PM
> To: Rosen, Brian
> Cc: [email-masked]
> G'Day All,
> I believe currently in the specification we have with reference to the
> terminationID:
> o Add with Choose "?" is valid and return 1 termination
> o Add with Specific is valid as it adds a specific termination.
> o Add with * is allowed as it adds per 7.2.1 1st para.
> o In the other commands then only specific or * is allowed.
>
> Given the current text it states that all matching terminations are
> attempted and results for each one are reported. That result could be
> OOS, termination ID is already in a context etc.
> Choung provided the clarification that OOS terminations can't
> be added.
>
> I must be missing something, where is the problem?
>
> What do we gain/loose if we remove the possibility of ADD with *? (To
> effect this change then I see we only need to update 7.2.1 1st
> paragraph).
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I think we have a significant issue to discuss and we might want
> > to think about changing some direction we have already given,
> > although I'm not sure how much text.
> >
> > Up to now, I, and others, have said that you can use a partially
> > wildcarded terminationId in a command such as Add using the ALL
> > construct, thus "abc*".
> >
> > This thread has caused me to wonder if this is wrong, and we
> > should really use CHOOSE, as others have suggested.  Here
> is my thinking:
> >
> > If we interpret ALL as the text states - equivalent to
> separate commands
> > with each matched terminationID, then "Add=abc*" where abcd
> and abce existed
> > would be equivalent to "Add=abcd{..., Add=abce{...."
> >
> > If we interpret CHOOSE as the text states - the MG chooses ONE
> > terminationId,
> > then "Add=abc?" could be interpreted by the MG as
> "Add=abcd" OR "Add=abce",
> > but only one, MG's choice.
> >
> > Given the issues on the thread:
> >
> >   You CAN get more than one Add out of a wildcard using ALL
> >   You would get an error if one of those matched
> terminations was OOS
> >   You CAN get only one Add of a wildcard using CHOOSE
> >   The MG would choose an MG that was In Service if, say,
> abce was OOS, it
> >     would choose abcd if asked to Add=abc?
> >
> > This allows the MGC to decide exactly how it wants partial
> wildcarded
> > commands to be done.  ALL might work well with Audit,
> CHOOSE might be
> > more appropriate with Add (in most cases anyway).
> >
> > Brian
> >
> > From: Chuong Nguyen [mailto:[email-masked]]
> > Sent: Tuesday, October 10, 2000 2:26 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 23 Oct 2000 11:09:15 -0400

Christian sums up the current state of the text.  He is asking whether we
want to deprecate a part of the protocol we have defined.  We could always
settle that one down the line, by seeing what people have demonstrated in
interoperability tests.

To answer Sachin's original question: the ADD command is enclosed by an
action.  In my view, the action is executed first, meaning that the
contextId is assigned a value before any Add is attempted.  The transaction
response will show the enclosing action with assigned contextId, followed by
the result for each command up to the first failed command without an "O-"
tag.  If all of the ADDs failed, the context is deleted immediately after
the transaction response is formulated.  I know that what I have just said
is slightly arbitrary, but I believe it provides a consistent point of view
which can guide implementations.

> From: Christian Groves [mailto:[email-masked]]