Subject: [Megaco] Re: Descriptor state after out of service

From: "Harry Suede" <[email-masked]>
Date: Tue, 04 Feb 2003 04:22:17 -0500

This means that ServiceChange does not change the descriptor of the termination and its upto MGC to change the descriptor. But consider this case that termination in non-null context is put to "out of service". Thus according to protocol all connections is lost. So at h/w level there is change but not in the database. Now if MG/MGC put termination back to "in service" does this mean that connection is to be re-established i.e. descriptors are to be reapply.
----- Original Message -----
From: Tom Taylor <[email-masked]>
Date: Mon, 03 Feb 2003 09:58:32 -0500
To: Harry Suede <[email-masked]>
Subject: Re: Descriptor state after out of service

> I don't believe the ServiceChange action does anything to the descriptors on its 
> own.  It is up to the MGC to reset them if necessary.  I do have the feeling that we 
> might want to analyze the situation and possibly refine it.
> 
> Harry Suede wrote:
> > Hi list, Tom
> > 
> > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line.
> > 
> > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not.
> > 
> > regards
> > harry
> 

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Meet Singles
http://corp.mail.com/lavalife

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Tom Taylor <[email-masked]>
Date: Tue, 04 Feb 2003 14:18:42 -0500

All ServiceChange does is advise the other end that it shouldn't be routing calls to 
this termination.  It does NOT, in itself, delete any connections (although an 
MG-initiated ServiceChange may reflect that a hardware or software failure has 
broken them).  We couldn't get more stringent than that because of the possibility 
you might want to route test calls through a termination before returning it to service.

Availability states are modelled much more elaborately in traditional management 
systems.  To say all that can be said takes more than one state variable.  We are 
just using one, and as a result its usefulness is limited.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 04 Feb 2003 14:18:42 -0500