Subject: Re: Service State Property "Out of Service"

From: Hemant Kumar <[email-masked]>
Date: Tue, 18 Apr 2000 19:46:33 +0530

Hi Michael, list,

    I please find my commnet below (marked <HKG> below)

Regards,
Hemant

----- Original Message -----
From: Michael Brown <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 18, 2000 4:07 AM
Subject: Re: Service State Property "Out of Service"

> Comments inserted inline with <MB>.
>
> Hemant wrote:
>
> > Hi Brian, list,     I wish to discuss some issues with handling of
> > service state property value "Out of Service" (OOS). The draft
> > mentions "The state "out of service" indicates that the termination
> > cannot be used for traffic" (sec 7.1.5 para 2). This is fine for the
> > terminations which are made OOS in null context as terminations can
> > only be Added with non "out of service" state. But what about the
> > following : 1) Is a command specifying Service State as OOS valid for
> > a termination in a non null context ?If it is valid, what is the MG
> > expected to do ? Should it stop traffic and deallocate all the
> > resources allocated for that termination and let the termination
> > remain in non null context? What will happen if this termination is
> > made "in-service" again. The MG would have to allocate all the
> > resources (according to the command in which the termination state
> > change is specified as in service) for this termination and add it to
> > the context. That is the MG would do all the handling that is required
> > to "Add" the termination in the context. Then what is being gained by
> > keeping a OOS termination in a non-NULL context ?
> >
> > <MB> Actually, I would expect that the MG would continue to do what it
> > is told to do either through control of the MGC or perhaps a
> > maintenance interface. The decision as to whether/when the termination
> > would stop traffic and deallocate resources would be based on the type
> > of service change requested (e.g., forced, etc.)

    <HKG>  What I meant to ask was what does the MG do on receiving service state OOS in Termination state descriptor. Service change handling is already specified in the draft.

The use for an OOS
> > termination in a non-null context is that that there are a number of
> > OOS tests which could be performed which would be easier modelled by
> > placing the termination into a context and potentially adding test
> > terminations to the context to perform those functions such as making
> > a test call to or from the OOS termination. I do not believe that the
> > operation should be made invalid.
> >
    <HKG> If tests have to be performed, I think that the MGC should set the
service state (in Termination State Descriptor) to Test rather than OOS.

> >   Suggestion : I would suggest that operation should be made invalid.
> > The MGC should first bring the termination out of context by
> > explicitly subtracting the termination. Another option is specifying
> > that setting state to OOS does an implicit subtract (just like mux
> > results in an implicit Add). But in this option what would a command
> > containing Stream desc. with non null Local or Remote mean ? Should
> > resource reservation implied by these be neglected ? I don't know why
> > one would like to make a temination OOS and then hold resources for
> > that same termination. 2) Assume that the state of a termination in
> > null context is In service. An add command for that termination is
> > received and in that command the termination state set to OOS. Is that
> > a valid command ? Suggestion : I think this should also be considered
> > invalid going by the logic which prevents an already OOS termination
> > to be added to a context. Can it be said then that changing the state
> > of a termination to OOS is valid only under following circumstances
> > :    - In null context.    - By Modify command.    - Without any Local
> > and Remote Descriptor.
> >
> > <MB> I would say that the command you have suggested is indeed
> > invalid. I think you meant to suggest that a transaction might contain
> > both an ADD command and a ServiceChange command and that this
> > combination should be invalid. I again do not agree that this should
> > be considered invalid, although I would think it somewhat unlikely
> > that one would want to do so.
> >

    <HKG> Please note that here I am referring to setting service state property in Termination state descriptor and what is meant is that an add command may contain service state OOS which I think is invalid. As for the case you have mentioned above I don't think that validation falls within the purview of the MG. Within an action, the MG should consider commands according to their priority.
Apologies for any underspecifications.

> >   comments please ....

Regards,
Hemant Kumar

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:[email-masked]
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Hemant Kumar <[email-masked]>
Date: Tue, 18 Apr 2000 20:04:17 +0530

Hi Brian, Tom, list,

    Pls consider the following comments ( inlined <HKG> )

Regards and thanks,
Hemant Kumar

    ----- Original Message -----
From: Rosen, Brian
To: Hemant ; [email-masked]
Sent: Tuesday, April 18, 2000 4:59 AM
Subject: RE: Service State Property "Out of Service"

I'd think you should not set a termination out of service unless it was in
null context (and thus would not have any media streams).

<HKG> I Agree. Regarding what Michael mentioned test might have to be
carried out in OOS state. I think that should be done in the service state
"Test" rather than "OOS"

Whether it should be illegal is another question.  I don't care.  I would
not
want setting the property to have side effects like moving to null, etc.

A line with at least "SHOULD" is needed I think.

<HKG>
(case : termination in non null context receives a command with service state OOS)
Think "SHALL" would me more appropriate and the MG NEEDS to send an error
code to indicate to the MGC that the termination is in a non null context
 and so its service state can't be changed to OOS). The error code can be
    433 - TerminationID is already in a Context

Another Error condition that needs to be identified here is the case when an
MGC attempts to Add an OOS terminaiton (Explicitly prohobited according to
the draft) but error code is not specified. An error code should be allocated here.
    4xx - TerminationId in OOS state

Third condition : A termination is presently in service and in null context. An Add commnad specifying service state OOS is received. Either of the above errore code should be used.