Re: [Megaco] Cancel Service Change (method=Graceful) mechanism

[Christian Groves <Christian.Groves@ericsson.com.au>]

Hello Kapil,

It seems Kevin is following up the "warmboot" thread.

For the method=graceful in a NULL context I would say its simply a case of the
MGC not requesting this termination. It may be useful when doing some sort of
scheduled maintenance on the MG.

Regards, Christian

knayar@hss.hns.com wrote:
> 
> Hi Christian
> 
> Thanks for your replies in line...
> You would have read my comments to Kevin's response. We would need some changes
> to the following if no other alternative is acceptable/ available:
> 1). Definition of reason "WarmBoot".
> 2). Definition of method "Restart" which currently states only "service will be
> restored on the specified Terminations"
> 
> BTW, I am inquisitive - if an MG would typically send a Service Change
> (method=Graceful) with finite delay for a termination in Null context. Any
> comments?
> 
> thanks,
> kapil nayar
> www.hssworld.com
> 
> Christian Groves <Christian.Groves@ericsson.com.au> on 02/04/2003 05:34:44 AM
> 
> To:   Kapil Nayar/HSS@HSS
> cc:   megaco@ietf.org
> 
> Subject:  Re: [Megaco] Cancel Service Change (method=Graceful) mechanism
> 
> Hello Kapil,
> 
> Please see my comments below.
> 
> Christian
> 
> knayar@hss.hns.com wrote:
> >
> > Hi
> >
> > It seems the protocol doesnot define any procedure for cancelling an earlier
> > Service Change (method=Graceful) on a non-root termination.
> >
> > Taking a practical case:
> > MG sends a Service Change (method=Graceful) on a termination with delay= 2
> > hours.
> > After 1 hour, MG realizes that it doesn't want to put the termination
> > out-of-service (after remaining 1 hour) as was earlier intended.
> > How to inform the MGC of the new intentions - cancel graceful..?
> > Sending Service Change (method =Restart) would mean that termination just came
> > InService and doesnot have any active descriptors, whereas this is not the
> case.
> 
> [CHG] Method = Restart, Reason Warm Boot would work as Kevin mentions.
> 
> >
> > Solution:
> > MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only
> > about the intentions.
> > MG sends Service Change (method = Forced) when the termination actually goes
> > out-of-service after 2 hours.
> > This ensures that if Service Change (method = Forced) never came, the
> intentions
> > of MG never got materialised.
> >
> > Does any body have an alternative solution? Please suggest.
> 
> [CHG] Why do you need to do this? The MGC should have a timer of 2 hours
> associated with that termination. So the MGC knows when to subtract the
> termination from the context. The MGC should not use this termination for
> traffic after it has subtracted it.
> 
> >
> > thanks,
> > kapil nayar
> > www.hssworld.com
> >
> > DISCLAIMER: This message is proprietary to Hughes Software Systems
> > Limited (HSS) and is intended solely for the use of the individual
> > to whom it is addressed. It may contain  privileged or confidential
> > information  and should not be circulated or used for any purpose other
> > than for what it is intended. If you have received this message in error,
> > please notify the originator immediately. If you are not the intended
> > recipient, you are notified that you are strictly prohibited from using,
> > copying, altering, or disclosing the contents of this message. HSS accepts
> > no responsibility for loss or damage arising from the use of the information
> > transmitted by this email including damage from virus.
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco